Opened 2 years ago

Last modified 2 years ago

#11315 new bug

GHC doesn't restore split objects

Reported by: snowleopard Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.10.3
Keywords: Cc: NeilMitchell, ezyang
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

While working on the new Shake-based build system I came across an annoying problem related to missing split objects (see note).

I still don't fully understand the reasons behind the problem, but I found that GHC doesn't restore missing split objects, as explained in the example below. I think this is a bug, but maybe this is actually a missing feature. I think it shouldn't be difficult to fix.

module Test (test) where

test :: Int
test = 0

I compile the above with ghc -split-objs Test.hs and get two split object files in Test_o_split. Then if I delete any of these files, or even the whole folder, and rerun ghc -split-objs Test.hs the compiler doesn't bother to restore split objects, pretending that everything is up-to-date. However, if I delete Test.o all object files are restored.

Another related issue reported by Neil Mitchell (which may be worth a separate ticket) is that even if we corrupt Test.o and rerun ghc -split-objs Test.hs, the compiler doesn't restore the object file (nor missing split objects) to the consistent state.


Note: The problem I have is described here: https://github.com/snowleopard/shaking-up-ghc/issues/30. It's not necessary to follow the link to understand this ticket, however I'd appreciate any insight you might have about the reasons behind the problem and/or a possible solution.

Change History (3)

comment:1 Changed 2 years ago by ezyang

The problem is, even though A_o_split is supposed to be considered output of compilation, the recompilation checkers for --make and -c (the ones that determine if the source is modified) only look at the merged o file (not the split objects) to see if they've gone away.

Distressingly, in the current scheme, it is unobvious whether or not a split object directory is complete or not. So this suggests that we have to atomically output some digest describing all of the split objects we expect to see. Recompilation avoidance, when running in split objects mode, checks to see if the digest is newer than the source file, and that all the files in the digest exist.

comment:2 Changed 2 years ago by thomie

I was hoping we could get rid of -split-objs, now that #8405 is implemented (function-sections).

comment:3 in reply to:  2 Changed 2 years ago by snowleopard

Replying to thomie:

I was hoping we could get rid of -split-objs, now that #8405 is implemented (function-sections).

Interesting. We can certainly experiment with function sections in the new build system, but as I understand we still need to provide full support for split objects.

Note: See TracTickets for help on using tickets.