The debian package seems to simply put un-stripped libraries into a special path (/usr/lib/debug/...). This should be relatively straight-forward to implement. Note though that from a look at the RPM infrastructure, they have a tool in there (dwarfread) which actually parses through DWARF information and updates paths, so there is possibly more going on here.
On the other hand, supporting -gsplit-dwarf seems to be a different mechanism, called Fission[1]. I haven't looked too much at the implementation yet, but to me it looks like it means generating copies of debug sections (such as .debug-line.dwo) which will then be extracted using "objcopy --extract-dwo". This might take a bit more work to implement, both on DWARF generation code as well as infrastructure.
Interestingly enough, doing this kind of splitting will actually buy us next to nothing - with Fission both .debug_line and .debug_frame would remain in the binary unchanged, so all we'd export would be some fairly inconsequential data from .debug_info. In contrast to other programming languages, we just don't have that much debug information in the first place. Well, at least not yet.
Greetings, Peter [1] https://gcc.gnu.org/wiki/DebugFission On 03/01/2015 00:18, Johan Tibell wrote:
Hi! We are now able to generate DWARF debug info, by passing -g to GHC. This will allow for better debugging (e.g. using GDB) and profiling (e.g. using Linux perf events). To make this feature more user accessible we need to ship debug info for the core libraries (and perhaps the RTS). The reason we need to ship debug info is that it's difficult, or impossible in the case of base, for the user to rebuild these libraries.The question is, how do we do this well? I don't think our "way" solution works very well. It causes us to recompile too much and GHC doesn't know which "ways" have been built or not. I believe other compilers, e.g. GCC, ship debug symbols in separate files (https://packages.debian.org/sid/libc-dbg) that e.g. GDB can then look up. -- Johan _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
