[GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv)

[GHC]

#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