How much debug info (as a percentage) do we currently generate? Could we just keep it in there in the release?
On Sat, Jan 3, 2015 at 1:33 PM, Peter Wortmann <sc...@leeds.ac.uk> wrote: > > > 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 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs