Hi Ben,
On Tue, 2015-08-25 at 12:59 +0200, Ben Gamari wrote:
> Right, we have a number of Darwin users and I still haven't figured out
> how we might support them. That being said I personally have little
> interest in putting time into proprietary platforms so I'm not terribly
> concerned.
Right
Mark Wielaard writes:
> On Sat, Aug 22, 2015 at 12:18:46PM +0200, Ben Gamari wrote:
>>
>> I actually ask because while we don't produce or use the .debug_ranges
>> section, they sneak into our executables from the C runtime system
>> objects. However, whatever is emitting it seems to be doing a
On Sat, Aug 22, 2015 at 12:18:46PM +0200, Ben Gamari wrote:
> Mark Wielaard writes:
>
> > On Fri, Aug 21, 2015 at 06:25:38PM +0200, Ben Gamari wrote:
> >> Does elfutils need .debug_ranges as well?
> >
> > Only if the DWARF producer created DIEs with DW_AT_ranges attributes.
> > You seem to never
Mark Wielaard writes:
> On Fri, Aug 21, 2015 at 06:25:38PM +0200, Ben Gamari wrote:
>> Does elfutils need .debug_ranges as well?
>
> Only if the DWARF producer created DIEs with DW_AT_ranges attributes.
> You seem to never do that. If your range is just one simple one you can
> just use a DW_AT_l
On Fri, Aug 21, 2015 at 06:25:38PM +0200, Ben Gamari wrote:
> Mark Wielaard writes:
>
> > And this is the problem. Sorry. I should have realized earlier.
> > We use the .debug_aranges to get a quick index of the CUs and which
> > address ranges they cover. In the case that there is no .debug_aran
On Fri, Aug 21, 2015 at 04:41:20PM +0200, Ben Gamari wrote:
> Mark Wielaard writes:
>
> > On Fri, Aug 21, 2015 at 09:35:14AM +0200, Ben Gamari wrote:
> >
> >> I have noticed that `/opt/exp/elfutils-root/bin/readelf -e
> >> ghc/stage2/build/Main.o --debug-dump=aranges` returns nothing for
> >> GHC
Mark Wielaard writes:
> And this is the problem. Sorry. I should have realized earlier.
> We use the .debug_aranges to get a quick index of the CUs and which
> address ranges they cover. In the case that there is no .debug_aranges
> we could do a full scan of all CUs. But that is somewhat ineffic
Mark Wielaard writes:
> On Fri, Aug 21, 2015 at 09:35:14AM +0200, Ben Gamari wrote:
>
>> I have noticed that `/opt/exp/elfutils-root/bin/readelf -e
>> ghc/stage2/build/Main.o --debug-dump=aranges` returns nothing for
>> GHC-produced objects whereas it does not for objects produced by GCC.
>
> And
On Fri, Aug 21, 2015 at 09:35:14AM +0200, Ben Gamari wrote:
> So I have added {low_high}_pc attributes to the compilation units yet
> elfutils' addr2line is still not giving me line information,
>
> $ addr2line -e inplace/lib/bin/ghc-stage2 0x427150
> /opt/exp/ghc/ghc//ghc/Main.hs:79
>
Mark Wielaard writes:
> On Thu, 2015-08-20 at 17:02 +0200, Ben Gamari wrote:
>> Fair enough. However, I was basing my original statement not on the
>> output of elfutils' readelf but instead on libdwfl data structures
>> dumped in gdb.
>>
>> As you may have realized by now, the problem begins in
On Thu, 2015-08-20 at 19:32 +0200, Mark Wielaard wrote:
> On Thu, 2015-08-20 at 10:06 -0700, Josh Stone wrote:
> > On 08/20/2015 08:32 AM, Mark Wielaard wrote:
> > > See Dwarf 4 2.17 Code Addresses and Ranges. In particular elfutils takes
> > > advantage of:
> > > "If an entity has no associated ma
On Thu, 2015-08-20 at 10:06 -0700, Josh Stone wrote:
> On 08/20/2015 08:32 AM, Mark Wielaard wrote:
> > See Dwarf 4 2.17 Code Addresses and Ranges. In particular elfutils takes
> > advantage of:
> > "If an entity has no associated machine code, none of these attributes
> > are specified."
>
> (A -
On 08/20/2015 08:32 AM, Mark Wielaard wrote:
> See Dwarf 4 2.17 Code Addresses and Ranges. In particular elfutils takes
> advantage of:
> "If an entity has no associated machine code, none of these attributes
> are specified."
(A -> B) does not give you (B -> A)!
That is, the spec does *not* say
On Thu, 2015-08-20 at 17:02 +0200, Ben Gamari wrote:
> Fair enough. However, I was basing my original statement not on the
> output of elfutils' readelf but instead on libdwfl data structures
> dumped in gdb.
>
> As you may have realized by now, the problem begins in
> dwfl_module_getsrc, which re
Mark Wielaard writes:
> On Thu, 2015-08-20 at 16:13 +0200, Ben Gamari wrote:
>> Mark Wielaard writes:
>> > Could you post the binary somewhere?
>> > Then I will take a look at what is going wrong.
>> >
>> It can be found here (sorry for the size),
>>
>> http://home.smart-cactus.org/~ben/ghc
On Thu, 2015-08-20 at 16:13 +0200, Ben Gamari wrote:
> Mark Wielaard writes:
> > Could you post the binary somewhere?
> > Then I will take a look at what is going wrong.
> >
> It can be found here (sorry for the size),
>
> http://home.smart-cactus.org/~ben/ghc-stage2
Thanks.
> With binutils
Mark Wielaard writes:
> On Thu, 2015-08-20 at 13:09 +0200, Ben Gamari wrote:
>> It turns out that libbacktrace only uses DWARF line information, not
>> the .debug_frames unwinding information.
>
> It might indeed be that libbacktrace only handles .eh_frame.
> If you already generate .debug_frame
On Thu, 2015-08-20 at 13:09 +0200, Ben Gamari wrote:
> It turns out that libbacktrace only uses DWARF line information, not
> the .debug_frames unwinding information.
It might indeed be that libbacktrace only handles .eh_frame.
If you already generate .debug_frame it should be easy to
generate .eh
Mark Wielaard writes:
> On Thu, 2015-08-20 at 14:47 +0200, Ben Gamari wrote:
>> Using elfutils 0.163, built by me with all dependencies available,
>>
>> $ /opt/exp/elfutils-root/bin/addr2line --version
>> addr2line (elfutils) 0.163
>> Copyright (C) 2012 Red Hat, Inc.
>> This is f
On Thu, 2015-08-20 at 14:47 +0200, Ben Gamari wrote:
> Using elfutils 0.163, built by me with all dependencies available,
>
> $ /opt/exp/elfutils-root/bin/addr2line --version
> addr2line (elfutils) 0.163
> Copyright (C) 2012 Red Hat, Inc.
> This is free software; see the source for
Ben Gamari writes:
> Ben Gamari writes:
>
snip
>
> Moreover, I have also implemented unwinding of the Haskell evaluation
> stack (the stack used by Haskell code). While the unwinding and symbol
> lookup work, I'm not getting any line information out of libdw. I'm
> quite certain that my object (
Ben Gamari writes:
> Mark Wielaard writes:
>
>> On Wed, 2015-08-19 at 14:11 +0200, Ben Gamari wrote:
>>> I am adding full DWARF unwinding-based backtrace support to the Glasgow
>>> Haskell Compiler's (GHC) runtime system. GHC now emits DWARF information
>>> in the object files it produces [1] an
Mark Wielaard writes:
> On Wed, 2015-08-19 at 14:11 +0200, Ben Gamari wrote:
>> I am adding full DWARF unwinding-based backtrace support to the Glasgow
>> Haskell Compiler's (GHC) runtime system. GHC now emits DWARF information
>> in the object files it produces [1] and we would like to be able t
On Wed, 2015-08-19 at 14:11 +0200, Ben Gamari wrote:
> I am adding full DWARF unwinding-based backtrace support to the Glasgow
> Haskell Compiler's (GHC) runtime system. GHC now emits DWARF information
> in the object files it produces [1] and we would like to be able to
> record full backtraces on
I am adding full DWARF unwinding-based backtrace support to the Glasgow
Haskell Compiler's (GHC) runtime system. GHC now emits DWARF information
in the object files it produces [1] and we would like to be able to
record full backtraces on both runtime system events and the user's
request.
The goal
25 matches
Mail list logo
