We are clearly trying to float past a breakpoint here, which is simply
impossible. Pretty sure this would have been a panic before my changes
too (it would have tried to mkNoCount the breakpoint). Guess I was
wrong reading a breakpoints don't appear here invariant out of that...
The quick
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
, Johan Tibell wrote:
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
mailto:sc...@leeds.ac.uk wrote:
Okay, I ran a little experiment - here's the size of the debug
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
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
At this point I have a bit more time on my hands again (modulo post-thesis
vacations), but we are basically still in “review hell”.
I think “just” for perf_events support we’d need the following patches[1]:
1. Source notes (Core support)
2. Source notes (CorePrep Stg support)
3. Source notes
.
Greetings,
Peter
On Wed, Aug 13, 2014 at 8:49 PM, Peter Wortmann
sc...@leeds.ac.ukmailto:sc...@leeds.ac.uk wrote:
At this point I have a bit more time on my hands again (modulo post-thesis
vacations), but we are basically still in “review hell”.
I think “just” for perf_events support we’d need
though -
my nick is petermw.
Greetings,
Peter Wortmann
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
. You are right in that this doesn't quite match the literal
interpretation of lexical scoping.
Greetings,
Peter Wortmann
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Added a few sentences about DWARF support - we should really aim to get
this done for 7.10.
Greetings,
Peter Wortmann
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Nathan Howell wrote:
I did get a language ID assigned a couple years ago, it should be in DWARF
5.
Accepted: DW_LANG_Haskell assigned value 0x18. -- April 18.2012
Nice work. We'll start using that one then :)
Greetings,
Peter Wortmann
Roman Cheplyaka wrote:
Or he's not subscribed to this list and his messages do not come through
Ah thanks, that's probably it. I accumulated lots of error mails from
the mailing list, which however didn't mention subscribing. Sorry about
the confusion...
Greetings,
Peter Wortmann
of the mangled name may be beneficial to
performance.
This might be the underlying reason why it shows mangled names for
languages with unknown IDs (such as Haskell). We'll see whether Johan's
query to the GDB team brings some light into that.
Greetings,
Peter Wortmann
. I investigated this some time ago, and I think the reason was that
it doesn't recognize the Haskell language ID (which isn't standardized,
obviously). Simply pretending to be C(++) might fix this, but I would be
a bit scared of other side-effects.
Greetings,
Peter Wortmann
14 matches
Mail list logo
