addr2line i mingw gcc 4.4.0

addr2line i mingw gcc 4.4.0

[björn lundin]

Hi!
Does anyone know how to get a valid libaddr2line.[dll|a]
for windows mingw 4.4.0?

I use the symbolic traceback, and it links aginst this lib, thus
making the
link fail with 'missing libaddr2line' message.

Looking in the ACT versions, the file is there, along with other
lib?.a
Looking in the mingw fsf vrsion, it is not there.

/Björn
--björn lundin

Re: addr2line i mingw gcc 4.4.0

[sjw]

On Jun 26, 3:41 pm, björn lundin <b.f.lun...@gmail.com> wrote:

> Does anyone know how to get a valid libaddr2line.[dll|a]
> for windows mingw 4.4.0?
>
> I use the symbolic traceback, and it links aginst this lib, thus
> making the
> link fail with 'missing libaddr2line' message.
>
> Looking in the ACT versions, the file is there, along with other
> lib?.a

Could you just copy from there?

Re: addr2line i mingw gcc 4.4.0

[björn lundin]

On 26 Juni, 22:56, sjw <simon.j.wri...@mac.com> wrote:

>> Looking in the ACT versions, the file is there, along with other
>> lib?.a
> Could you just copy from there?

Should perhaps mentioned that I already tried that. Links OK but gives
Program_Error at runtime,
some Access_Violation thingy
Also, I would prefer to have it from the gcc I'm using
/Björn

Re: addr2line i mingw gcc 4.4.0

[Ludovic Brenta]

Björn Lundin wrote on comp.lang.ada:
> On 26 Juni, 22:56, sjw <simon.j.wri...@mac.com> wrote:
>
> >> Looking in the ACT versions, the file is there, along with other
> >> lib?.a
> > Could you just copy from there?
>
> Should perhaps mentioned that I already tried that. Links OK but gives
> Program_Error at runtime,
> some Access_Violation thingy
> Also, I would prefer to have it from the gcc I'm using

libaddr2line.a is an invention from AdaCore several years ago; it is a
patch against the program "addr2line" in certain versions of binutils,
not GCC.  I am not aware of any binary distribution of it apart from
AdaCore's own.  In Debian, I've patched GCC so that it supports
symbolic tracebacks by calling addr2line in an external process rather
than using libaddr2line in-process.  An early version of this patch
was in the Ada for Linux Team distribution by Jürgen Pfeiffer for Red
Hat Linux 6 (in 1999).

So, I think you can have symbolic tracebacks in mingw in one of two
ways: patch binutils to build libaddr2line.a then link libgnat against
it; or patch libgnat to use the same method as on Debian.

HTH

--
Ludovic Brenta.

Re: addr2line i mingw gcc 4.4.0

[Stephen Leake]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Bj�rn Lundin wrote on comp.lang.ada:
>> On 26 Juni, 22:56, sjw <simon.j.wri...@mac.com> wrote:
>>
>> >> Looking in the ACT versions, the file is there, along with other
>> >> lib?.a
>> > Could you just copy from there?
>>
>> Should perhaps mentioned that I already tried that. Links OK but gives
>> Program_Error at runtime,
>> some Access_Violation thingy
>> Also, I would prefer to have it from the gcc I'm using
>
> libaddr2line.a is an invention from AdaCore several years ago; it is a
> patch against the program "addr2line" in certain versions of binutils,
> not GCC.  I am not aware of any binary distribution of it apart from
> AdaCore's own.  In Debian, I've patched GCC so that it supports
> symbolic tracebacks by calling addr2line in an external process rather
> than using libaddr2line in-process.  An early version of this patch
> was in the Ada for Linux Team distribution by J�rgen Pfeiffer for Red
> Hat Linux 6 (in 1999).
>
> So, I think you can have symbolic tracebacks in mingw in one of two
> ways: patch binutils to build libaddr2line.a then link libgnat against
> it; or patch libgnat to use the same method as on Debian.

A third alternative is to output numeric traceback from the failing
program, and then use addr2line (the program) to get the symbolic
traceback in a separate manual step.

I use this approach. It reduces the amount of output significantly;
there are many times that a traceback is generated by I don't want to
peruse it.

Ludovic's approach simply automates this.

-- 
-- Stephe

Re: addr2line i mingw gcc 4.4.0

[Dmitry A. Kazakov]

On Sat, 27 Jun 2009 07:28:32 -0400, Stephen Leake wrote:

> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
> 
>> libaddr2line.a is an invention from AdaCore several years ago; it is a
>> patch against the program "addr2line" in certain versions of binutils,
>> not GCC.  I am not aware of any binary distribution of it apart from
>> AdaCore's own.  In Debian, I've patched GCC so that it supports
>> symbolic tracebacks by calling addr2line in an external process rather
>> than using libaddr2line in-process.  An early version of this patch
>> was in the Ada for Linux Team distribution by J�rgen Pfeiffer for Red
>> Hat Linux 6 (in 1999).
>>
>> So, I think you can have symbolic tracebacks in mingw in one of two
>> ways: patch binutils to build libaddr2line.a then link libgnat against
>> it; or patch libgnat to use the same method as on Debian.
> 
> A third alternative is to output numeric traceback from the failing
> program, and then use addr2line (the program) to get the symbolic
> traceback in a separate manual step.

It is quite simple to print the symbolic traceback from the program:

with Ada.Text_IO;              use Ada.Text_IO;
with GNAT.Traceback;           use GNAT.Traceback;
with GNAT.Traceback.Symbolic;  use GNAT.Traceback.Symbolic;

procedure Call_Stack is
   TB  : Tracebacks_Array (1..100);
   Len : Natural;
begin
   Call_Chain (TB, Len);
   Put_Line (Symbolic_Traceback (TB (1..Len)));
end Call_Stack; 

This prints the call stack. I am using this for tracing Gtk errors before
they corrupt the stack due to exception propagation.

Note that Tracebacks_Array is merely an array of addresses, so if you get
it in other way, for example, from Exception_Information, you can convert
each number there to Address (using System.Storage_Elements.To_Address) and
then pass the result to (Symbolic_Traceback.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: addr2line i mingw gcc 4.4.0

[Ludovic Brenta]

On Jun 27, 2:29 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sat, 27 Jun 2009 07:28:32 -0400, Stephen Leake wrote:
> > Ludovic Brenta <ludo...@ludovic-brenta.org> writes:
>
> >> libaddr2line.a is an invention from AdaCore several years ago; it is a
> >> patch against the program "addr2line" in certain versions of binutils,
> >> not GCC.  I am not aware of any binary distribution of it apart from
> >> AdaCore's own.  In Debian, I've patched GCC so that it supports
> >> symbolic tracebacks by calling addr2line in an external process rather
> >> than using libaddr2line in-process.  An early version of this patch
> >> was in the Ada for Linux Team distribution by Jürgen Pfeiffer for Red
> >> Hat Linux 6 (in 1999).
>
> >> So, I think you can have symbolic tracebacks in mingw in one of two
> >> ways: patch binutils to build libaddr2line.a then link libgnat against
> >> it; or patch libgnat to use the same method as on Debian.
>
> > A third alternative is to output numeric traceback from the failing
> > program, and then use addr2line (the program) to get the symbolic
> > traceback in a separate manual step.
>
> It is quite simple to print the symbolic traceback from the program:
>
> with Ada.Text_IO;              use Ada.Text_IO;
> with GNAT.Traceback;           use GNAT.Traceback;
> with GNAT.Traceback.Symbolic;  use GNAT.Traceback.Symbolic;
>
> procedure Call_Stack is
>    TB  : Tracebacks_Array (1..100);
>    Len : Natural;
> begin
>    Call_Chain (TB, Len);
>    Put_Line (Symbolic_Traceback (TB (1..Len)));
> end Call_Stack;
>
> This prints the call stack. I am using this for tracing Gtk errors before
> they corrupt the stack due to exception propagation.
>
> Note that Tracebacks_Array is merely an array of addresses, so if you get
> it in other way, for example, from Exception_Information, you can convert
> each number there to Address (using System.Storage_Elements.To_Address) and
> then pass the result to (Symbolic_Traceback.

Like I explained, this works in GNAT GPL Edition only because this
distribution includes libaddr2line.a, which GNAT.Tracebacks.Symbolic
uses.  For GCC, a patch is required either to binutils or to GCC
(libgnat, actually) itself.

--
Ludovic Brenta.

Re: addr2line i mingw gcc 4.4.0

[sjw]

On Jun 27, 12:28 pm, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> Ludovic Brenta <ludo...@ludovic-brenta.org> writes:
...
> > So, I think you can have symbolic tracebacks in mingw in one of two
> > ways: patch binutils to build libaddr2line.a then link libgnat against
> > it; or patch libgnat to use the same method as on Debian.
>
> A third alternative is to output numeric traceback from the failing
> program, and then use addr2line (the program) to get the symbolic
> traceback in a separate manual step.
>
> I use this approach. It reduces the amount of output significantly;
> there are many times that a traceback is generated by I don't want to
> peruse it.
>
> Ludovic's approach simply automates this.

On Darwin, there's a native program atos which does the same as
addr2line.

If your target is VxWorks symbolic tracebacks don't work at all; you
have to use addr2line (well, in VxWorks 5 executables are relocatable
but stack addresses are absolute; so you actually use a wrapper
{powerpc}-wrs-vxworks-vxaddr2line which works by referencing the
runtime address of adainit to its offset in the executable).

Re: addr2line i mingw gcc 4.4.0

[björn lundin]

On 27 Juni, 18:24, sjw <simon.j.wri...@mac.com> wrote:
> On Jun 27, 12:28 pm, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>
> > Ludovic Brenta <ludo...@ludovic-brenta.org> writes:
> ...
> > > So, I think you can have symbolic tracebacks in mingw in one of two
> > > ways: patch binutils to build libaddr2line.a then link libgnat against
> > > it; or patch libgnat to use the same method as on Debian.

Hmm, this is way over my head...

> > A third alternative is to output numeric traceback from the failing
> > program, and then use addr2line (the program) to get the symbolic
> > traceback in a separate manual step.

This I recognize. I had to do this with the Gnat pro 5.Something,
on AIX, before the symbolic traceback was fixed there, a couple of
years ago.
This seems to be the most reasonably approach at this time.

> On Darwin, there's a native program atos which does the same as
> addr2line.
>
> If your target is VxWorks symbolic tracebacks don't work at all;

My target is Windows on x86 but thanks for the heads up

Reason I'm not using the gnat gpl version is that I try to use
the same compiler-suite for the ada code as wells as the c++ code.
This is now on visual studio, but I think its overkill for 5 c++ files
compared to 2000+ ada-files.

Or I just have to have 2 different gcc onboard, GPL for ada and FSF
for c++.
But it's not ideal.

Thank you all for the input

/Björn
björn lundin

Re: addr2line i mingw gcc 4.4.0

[Georg Bauhaus]

sjw wrote:

>> A third alternative is to output numeric traceback from the failing
>> program, and then use addr2line (the program) to get the symbolic
>> traceback in a separate manual step.

> On Darwin, there's a native program atos which does the same as
> addr2line.

Numbers and addr2line has the additional
advantage of easily switching Ada runtimes
in a testing environment:
ObjectAda for example uses a program named
postmort which reads numeric traces and
turns them into names and source lines.

Re: addr2line i mingw gcc 4.4.0

[Randy Brukardt]

"Georg Bauhaus" <see.reply.to@maps.futureapps.de> wrote in message 
news:4a4685ca$0$31336$9b4e6d93@newsspool4.arcor-online.net...
...
>> On Darwin, there's a native program atos which does the same as
>> addr2line.
>
> Numbers and addr2line has the additional
> advantage of easily switching Ada runtimes
> in a testing environment:
> ObjectAda for example uses a program named
> postmort which reads numeric traces and
> turns them into names and source lines.

For Janus/Ada, this is an integral part of the generated code; we don't 
provide addresses (nor is there any way to get addresses ever if you wanted 
them - stack walking is not reliable if foreign language code is involved, 
as it usually is). There is a way to completely suppress this code if 
performance is more important than debugging (as might be the case for some 
embedded targets).

                                Randy.

Re: addr2line i mingw gcc 4.4.0

[sjw]

On Jun 27, 5:24 pm, sjw <simon.j.wri...@mac.com> wrote:

> On Darwin, there's a native program atos which does the same as
> addr2line.

Hmm, what it does is to give you the offset in bytes from the start of
the subprogram.

package__subprogram ........ +57

which is fine if all you need is the subprograms on the call path.


GNAT GPL 2009 contains an addr2line (for 64-bit executables).

Re: addr2line i mingw gcc 4.4.0

[Robert A Duff]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> A third alternative is to output numeric traceback from the failing
> program, and then use addr2line (the program) to get the symbolic
> traceback in a separate manual step.

This is the approach usually recommended by AdaCore.  The reason you
want a traceback is because "something's wrong".  And that might
mean that memory has been corrupted.  The symbolic traceback
mechanism is pretty heavy, and therefore more likely to trip
over that corrupted memory.

So the approach mentioned by Stephen above is more robust.
It's also more efficient, because the symbolic traceback
mechanism is not part of your program -- it's in the separate
addr2line program.

- Bob