I've been building the RTS with debug symbols for our internal GHC build
at FB, because it makes investigating problems a lot easier. I should
probably upstream this patch.
Shipping libraries with debug symbols should be fine, as long as they
can be stripped - Peter, does stripping remove
Could we get this for 7.10 so our debug info story is more well-rounded?
On Fri, Jan 9, 2015 at 5:11 PM, Simon Marlow marlo...@gmail.com wrote:
I've been building the RTS with debug symbols for our internal GHC build
at FB, because it makes investigating problems a lot easier. I should
Yes - strip will catch everything.
Greetings,
Peter
On 09/01/2015 17:11, Simon Marlow wrote:
I've been building the RTS with debug symbols for our internal GHC build
at FB, because it makes investigating problems a lot easier. I should
probably upstream this patch.
Shipping libraries
We should merge this fix to the 7.10 branch.
On Jan 8, 2015 11:52 PM, Peter Wortmann sc...@leeds.ac.uk wrote:
(sorry for late answer)
Yes, that's pretty much what this would boil down to. The patch is trivial:
https://github.com/scpmw/ghc/commit/29acc#diff-1
I think this is a good idea
(sorry for late answer)
Yes, that's pretty much what this would boil down to. The patch is trivial:
https://github.com/scpmw/ghc/commit/29acc#diff-1
I think this is a good idea anyways. We can always re-introduce the data
for higher -gn levels.
Greetings,
Peter
On 05/01/2015 00:59,
Okay, I ran a little experiment - here's the size of the debug sections
that Fission would keep (for base library):
.debug_abbrev: 8932 - 0.06%
.debug_line: 374134 - 2.6%
.debug_frame: 671200 - 4.5%
Not that much. On the other hand, .debug_info is a
What about keeping exactly what -g1 keeps for gcc (i.e. functions, external
variables, and line number tables)?
On Sun, Jan 4, 2015 at 5:48 PM, Peter Wortmann sc...@leeds.ac.uk wrote:
Okay, I ran a little experiment - here's the size of the debug sections
that Fission would keep (for base
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
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
Brandon,
If we just built GHC with debug symbols enabled, everything should just
work from a packaging perspective?
On Fri, Jan 2, 2015 at 7:26 PM, Brandon Allbery allber...@gmail.com wrote:
On Fri, Jan 2, 2015 at 6:18 PM, Johan Tibell johan.tib...@gmail.com
wrote:
I believe other
On Fri, Jan 2, 2015 at 6:18 PM, Johan Tibell johan.tib...@gmail.com wrote:
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.
Lookaside debugging information is (a) a Linux-ism, although
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
On Fri, Jan 2, 2015 at 7:54 PM, Johan Tibell johan.tib...@gmail.com wrote:
If we just built GHC with debug symbols enabled, everything should just
work from a packaging perspective?
On most RPM systems, at least (I get debuginfo packages for local RPM
builds, with nothing special in the specs
13 matches
Mail list logo
