Fix for #15040: Make dtrace enabled GHC work as a bootstrap compiler on FreeBSD

Authored by raichoo on Jun 2 2018, 5:46 PM.



Since 8.4.1 GHC DTrace works are enabled on FreeBSD, 8.4.2 introduced a flag to turn off DTrace support since this interfered with GHC's ability to work as a bootstrap compiler. This patch enables GHC to have DTrace enabled as well as being able to function as a bootstrap compiler.

Diff Detail

rGHC Glasgow Haskell Compiler
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
raichoo created this revision.Jun 2 2018, 5:46 PM
bgamari requested changes to this revision.Jun 2 2018, 5:50 PM


Can we have a comment describing what is going on here? In what way are these objects "excluded"?

This revision now requires changes to proceed.Jun 2 2018, 5:50 PM

Sure thing.

The objects are excluded from the big object file I generate to make the dtrace probes work (that one gets stored in the archive). The reason why I'm doing this is stated in this thread answered by one of the dtrace developers from over a decade ago That poses a problem when trying to use it for linking the RTS for a compiler you are currently bootstrapping because now the hooks show up twice. I basically moved the hooks out of the object file I'm generating and put them into the archive separately. The hooks should have never been in the object file in the first place but I wasn't aware that they exist, let alone that it would cause any issues. The "EXCLUDED" variable gives a way to exclude files from the large object that I generate during linking (maybe one needs to exclude a couple more in the future, for yet unknown reasons). It basically allows for a bit more fine grained control when linking, which is currently only important for dtrace on FreeBSD and possibly other systems (apart from OSX) that have dtrace.

raichoo updated this revision to Diff 16674.Jun 3 2018, 3:02 AM

I've packed everything into a commented and extended the comment on the linking step for dtrace. I've added the only source of documentation I've found where the reason why I'm doing is is explained.

simonmar added inline comments.Jun 4 2018, 3:00 AM

Can we reference the ticket or more information to understand why it's necessary to exclude these particular objects?

raichoo added inline comments.Jun 4 2018, 4:03 AM

The objects are not being excluded from the archive they are being excluded from the RTS.o that I create (see line 278). The object files still end up in the archive. If I put these into the RTS.o (which needs to be created to make dtrace work on FreeBSD) this will result in linking errors when bootstrapping another compiler.

/usr/bin/ld: error: duplicate symbol: StackOverflowHook
>>> defined at hschooks.c
>>>            ghc/stage1/build/hschooks.o:(StackOverflowHook)
>>> defined at OSMem.c
>>>            RTS.o:(.text.StackOverflowHook+0x0) in archive /usr/local/lib/ghc-8.4.2/rts/libHSrts.a

I can put this information into the ticket and reference it in this comment.

raichoo updated this revision to Diff 16704.Jun 4 2018, 3:10 PM
raichoo marked 2 inline comments as done.
simonmar added inline comments.Jun 5 2018, 5:14 AM

It's fine to reference tickets just as #15040 without the full URL.

raichoo updated this revision to Diff 16719.Jun 5 2018, 6:04 AM
raichoo marked an inline comment as done.
bgamari accepted this revision.Jun 15 2018, 1:07 PM



Thanks for the reference! This helps a lot.

This revision is now accepted and ready to land.Jun 15 2018, 1:07 PM
This revision was automatically updated to reflect the committed changes.
bgamari added a comment.EditedSep 22 2018, 11:29 AM

Unfortunately I'm seeing undefined symbol errors when GHC is built on FreeBSD 11 with DTrace enabled (see the later comments in Trac #4022). @raichoo, could you investigate?