#9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by jberthold): Replying to [comment:2 ezyang]:
Oof, sorry about breaking backwards compatibility in such an annoying way.
I think we should have some "warning signs" in the code (includes/rts/Constants.h), otherwise this will happen again sooner or later. The shared knowledge of ghc-events and GHC runtime system is in includes/rts/EventLogFormat, which is obviously not up to date right now. includes/rts/Constants.h should point there. About the options:
1. Accept that `includes/Constants.h` really is GHC internal
Decidedly not the intention (for the parts mentioned in EventLogFormat.h). The other commit you found is interesting... My best guess is tha "Relocated" was never actually written to an event log (I might be wrong, though...)
2. Establish the constants as a proper ABI which we guarantee the stability of, and add comments and test-cases to prevent people from renumbering them to maintain cleanliness.We can take this further and consider the state of affairs in 7.8.2 to be a bug,
This is what Simon thought of, judging from what he replied to my mail earlier. I completely agree with you, there have to be comments in the code to avoid this in the future. Then either 2a) ghc-events stays as it is and will never parse ghc-7.8.2 eventlogs 100% correctly 2b) GHC and ghc-events are adapted to recognise ghc-7.8.2 traces (and not later versions) from their header, by adding an event or extending one with a new field, in GHC-7.8.3. Or there might be 3. Consider older ghc-events versions outdated (something we wanted to avoid), and only adapt ghc-events. This is what I did for the fork ghc- events-parallel (but it leaves the route to 2B open). And: Yes, an event indicating the RTS version is written by (newer versions of) GHC. However, we cannot rely on it being present, and it is fiddly/fragile to read the beginning of an eventlog and then switch parsers when (and iff) it is found. I tried that, but then went for the other fix. The information must be derived from the header (event information), not from events that may or may not be written. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9003#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler