Re: GCC stack backtraces

[Janne Blomqvist]

On Wed, Aug 29, 2012 at 10:22 AM, Ian Lance Taylor  wrote:
> I've spent the last couple of days working on a stack backtrace library.
>
> It uses the GCC unwind interface to collect a stack trace, and parses
> DWARF debug info to get file/line/function information.
[snip]
> I expect to use this code not just for GCC proper, but also for libgo
> (currently libgo uses Go code to parse DWARF, but that is not very
> satisfactory as that code is only available if it has been imported into
> the program).  So I put it under a BSD license, although that is open
> for discussion.  Also in case it finds more uses elsewhere I wrote it in
> reasonably portable C rather than C++.
>
>
> Does this seem like something we could usefully add to GCC?  Does
> anybody see any big problems with it?

I haven't looked at the code, but if it is async-signal-safe it could
be interesting for gfortran. Currently in libgfortran we have a
backtracing routine, originally written by FX Coudert IIRC, since
rewritten by yours truly a few times, that uses _Unwind_Backtrace()
from libgcc and then pipes the output via addr2line, if found. Since
it's invoked from a signal handler when the program (user program, not
the compiler!) crashes, it needs to be async-signal-safe. AFAIK the
current implementation *should* fulfill that requirement. But
something that would be async-signal-safe and won't need addr2line to
get symbolic info would be a nice improvement, in particular since
addr2line doesn't work on OSX, and all that piping stuff doesn't work
on Windows.


-- 
Janne Blomqvist

Re: GCC stack backtraces

[Gabriel Dos Reis]

On Wed, Aug 29, 2012 at 2:22 AM, Ian Lance Taylor  wrote:

> Does this seem like something we could usefully add to GCC?

Emphatically, yes!.

>  Does anybody see any big problems with it?

Can it would be a great addition to libstdc++ as a GNU extension, stached
in the  namespace.

I do also do like the fact that you're planning a BSD licence; that means I can
make use of it in my own projects.

> The library is not quite ready to commit, but it's quite close.  It just
> needs a bit more testing in uncommon build environments, i.e., anything
> other than x86_64 GNU/Linux, to make sure that it at least builds and
> does not crash even when it can't get a backtrace.


Kudos for doing this.  I am sure Diego would love it (when he is back.)

-- Gaby

Re: GCC stack backtraces

[Basile Starynkevitch]

On Wed, Aug 29, 2012 at 02:47:18AM -0500, Gabriel Dos Reis wrote:
> On Wed, Aug 29, 2012 at 2:22 AM, Ian Lance Taylor  wrote:
> 
> > Does this seem like something we could usefully add to GCC?
> 
> Emphatically, yes!.


I also think it would be very useful.

BTW, MELT has also such a feature (which proved extremely useful in daily use, 
so I am sure that if something existed in GCC it would help a lot many GCC 
developers), 
but it is simpler because MELT call frames are 
explicit (linked) C struct-s (generated by the MELT translator), and there is
some location slot inside them. So MELT can output backtraces like e.g.


SHORT BACKTRACE[#0] warmelt-first.melt:2809: MELT CHECK: 
meltmod__warmelt_first__initialmeltchunk_39 {putroutconst 
constnull.drout_3199__INITVALUE_EXPORTER#0};
#1:_ warmelt-first.melt:2801:/ initchunk

#2:_ melt-runtime.c:9000:: meltgc_start_module_by_index before starting #1 
/usr/src/Lang/basile-melt-gcc/gcc/melt/generated/warmelt-first

#3:_ melt-runtime.c:9038:: meltgc_start_all_new_modules before starting #1 
module 
/usr/src/Lang/_Obj_Melt_Basile/gcc/meltbuild-stage0-dynamic/warmelt-first.meltmod-675464a27b5d1fd9709f280cd71315ef.dynami

#4:_ melt-runtime.c:9675:: meltgc_load_modules_and_do_mode before loading 
curmod meltbuild-stage0-dynamic/warmelt-modes.dynamic


Cheers.
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: GCC stack backtraces

[Paweł Sikora]

On Wednesday 29 of August 2012 00:22:55 Ian Lance Taylor wrote:
> I've spent the last couple of days working on a stack backtrace library.
> 
> It uses the GCC unwind interface to collect a stack trace, and parses
> DWARF debug info to get file/line/function information.  (Of course it's
> silly to write yet another DWARF reader, but I didn't find an existing
> reader that seemed wholly suitable.)

isn't the libdwarf a good enough for reading?

http://reality.sgiweb.org/davea/dwarf.html

Re: GCC stack backtraces

[Basile Starynkevitch]

On Wed, Aug 29, 2012 at 10:07:30AM +0200, Paweł Sikora wrote:
> On Wednesday 29 of August 2012 00:22:55 Ian Lance Taylor wrote:
> > I've spent the last couple of days working on a stack backtrace library.
> > 
> > It uses the GCC unwind interface to collect a stack trace, and parses
> > DWARF debug info to get file/line/function information.  (Of course it's
> > silly to write yet another DWARF reader, but I didn't find an existing
> > reader that seemed wholly suitable.)
> 
> isn't the libdwarf a good enough for reading?
> 
> http://reality.sgiweb.org/davea/dwarf.html

If Ian's DWARF reader is simple enough (since suited for a single purpose), 
it might be helpful to avoid yet another external library dependency for GCC.

Regards
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

detecting if cross-compiler (in plugin)?

[Basile Starynkevitch]

Hello All,

What is the simplest way, for a plugin (and also for a GCC branch), 
to detect if the compiler is straight or not (i.e. cross, that is 
target & host are different, or even canadian-cross).

I was thinking of some macro in auto-host.h or other header.

(MELT is, during its building procedure, testing itself by running 
a simple MELT pass on the MELT runtime. Obviously this step makes 
no sense for cross compilers, hence the question)

Cheers
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

RE: ICE with MEM_REF when Pmode is different from word_mode

[Deepti Sharma]

Hello Richard,

> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Richard Guenther
> Sent: 31 May 2012 14:27
> To: Mohamed Shafi
> Cc: GCC; d...@redhat.com; Ahmed Sherif
> Subject: Re: ICE with MEM_REF when Pmode is different from word_mode
> 
> On Wed, May 30, 2012 at 4:31 PM, Mohamed Shafi 
> wrote:
> > On 29 May 2012 17:31, Richard Guenther 
> wrote:
> >> On Tue, May 29, 2012 at 1:57 PM, Mohamed Shafi 
> wrote:
> >>> Hi,
> >>>
> >>> I am porting a private target in GCC 4.6.3 version. For my target
> >>> pointer size is 24bits and word size is 32bits. Moreover a byte is
> >>> 32bit
> >>>
> >>> For the testcase gcc.c-torture/compile/92-1.c i get the
> >>> following ICE
> >>>
> >>> 92-1.c: In function 'f':
> >>> 92-1.c:18:5: internal compiler error: in size_binop_loc, at
> >>> fold-const.c:1436
> >>> Please submit a full bug report,
> >>> with preprocessed source if appropriate.
> >>> See  for instructions
> >>>
> >>> This is the reduced testcase of the same
> >>>
> >>>  struct vp {
> >>>  int wa;
> >>> };
> >>>
> >>> typedef struct vp *vpt;
> >>>
> >>> typedef struct vc {
> >>>  int o;
> >>>  vpt py[8];
> >>> } *vct;
> >>>
> >>> typedef struct np *npt;
> >>> struct np {
> >>>  vct d;
> >>>  int di;
> >>> };
> >>>
> >>> int f(npt dp)
> >>> {
> >>>  vpt *py;
> >>>
> >>>  py = &dp->d->py[dp->di];
> >>>  return (int)(py[1])->wa;
> >>> }
> >>>
> >>> The ICE happens in tree_slp_vectorizer pass. The following is the
> >>> tree dump just before that
> >>>
> >>> ;; Function f (f)
> >>>
> >>> f (struct np * dp)
> >>> {
> >>>  struct vp * D.1232;
> >>>  int D.1230;
> >>>  unsigned int D.1228;
> >>>  int D.1227;
> >>>  struct vc * D.1225;
> >>>
> >>> :
> >>>  D.1225_2 = dp_1(D)->d;
> >>>  D.1227_4 = dp_1(D)->di;
> >>>  D.1228_5 = (unsigned int) D.1227_4;
> >>>  D.1232_9 = MEM[(struct vp * *)D.1225_2 + 4B].py[D.1228_5]{lb: 0
> sz:
> >>> 4};
> >>>  D.1230_10 = D.1232_9->wa;
> >>>  return D.1230_10;
> >>> }
> >>>
> >>> The ICE happens for
> >>>
> >>>  D.1232_9 = MEM[(struct vp * *)D.1225_2 + 4B].py[D.1228_5]{lb: 0
> sz:
> >>> 4};
> >>>
> >>> This is due to the addition of the new code in tree-data-ref.c
> (this
> >>> is was not there in 4.5 series)
> >>>
> >>>  if (TREE_CODE (base) == MEM_REF)
> >>>    {
> >>>      if (!integer_zerop (TREE_OPERAND (base, 1)))
> >>>        {
> >>>          if (!poffset)
> >>>            {
> >>>              double_int moff = mem_ref_offset (base);
> >>>              poffset = double_int_to_tree (sizetype, moff);
> >>>            }
> >>>          else
> >>>            poffset = size_binop (PLUS_EXPR, poffset, TREE_OPERAND
> >>> (base, 1));
> >>
> >> This should use mem_ref_offset, too.
> >>
> >
> > This is present in the trunk also. Will you be submitting a patch for
> this?
> 
> I put it on my TODO list.  Something like
 
Is this issue fixed now for gcc 4.6.3? I am not able to find a bug entry for
this. Could you please share the link?

Thanks.


> Index: gcc/tree-data-ref.c
> ===
> --- gcc/tree-data-ref.c (revision 188008)
> +++ gcc/tree-data-ref.c (working copy)
> @@ -720,13 +720,12 @@ dr_analyze_innermost (struct data_refere
>  {
>if (!integer_zerop (TREE_OPERAND (base, 1)))
> {
> + double_int moff = mem_ref_offset (base);
> + tree mofft = double_int_to_tree (sizetype, moff);
>   if (!poffset)
> -   {
> - double_int moff = mem_ref_offset (base);
> - poffset = double_int_to_tree (sizetype, moff);
> -   }
> +   poffset = mofft;
>   else
> -   poffset = size_binop (PLUS_EXPR, poffset, TREE_OPERAND
> (base, 1));
> +   poffset = size_binop (PLUS_EXPR, poffset, mofft);
> }
>base = TREE_OPERAND (base, 0);
>  }
> 
> 
> > Shafi

trunk merged into MELT branch after C++ conversion

[Basile Starynkevitch]

Hello All,

I just successfully merged the trunk (future GCC 4.8) svn rev 190745 
into the MELT (www.gcc-melt.org) branch (svn rev 190778). 
In particular, this meant merging the C++ conversion into the MELT branch.

That merge was a bit painful, because of the C -> C++ conversion.
Most of the pain was build procedure related.

The PPL related code has been entirely removed from MELT.

I discovered a strange property of C++ regarding symbols. If you just code

   // file foo1.cc
   extern "C" { 
 const int twosymb=2;
   };

the resulting foo1.o does not define a twosymb symbol (I expected that it does).
You have to code

   // file foo2.cc
   extern "C" {
 extern const int twosymb;
 const int twosymb=2;
   };
   
to get a symbol "twosymb" in foo2.o

I expect the next release of MELT plugin to be compatible with GCC 4.7, 
also hopefully perhaps still with GCC 4.6, and with the trunk (i.e. 4.8).

Regards.
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: trunk merged into MELT branch after C++ conversion

[Marc Glisse]

On Wed, 29 Aug 2012, Basile Starynkevitch wrote:


I discovered a strange property of C++ regarding symbols. If you just code

  // file foo1.cc
  extern "C" {
const int twosymb=2;
  };

the resulting foo1.o does not define a twosymb symbol (I expected that it does).
You have to code

  // file foo2.cc
  extern "C" {
extern const int twosymb;
const int twosymb=2;
  };

to get a symbol "twosymb" in foo2.o


Yes, that's one of the usual traps about C vs C++. Note that you can write 
everything on the same line...


extern "C" const int twosymb = 2;

--
Marc Glisse

Re: GCC stack backtraces

[Michael Matz]

Hi,

On Wed, 29 Aug 2012, Ian Lance Taylor wrote:

> Does this seem like something we could usefully add to GCC?  Does 
> anybody see any big problems with it?

Does it work without unwind tables?  I suspect it doesn't as it's using 
libgccs unwinder, so that would be a problem if we were to use it to 
generally replace our current non-backtrace based means.


Ciao,
Michael.

Re: GCC stack backtraces

[Frank Ch. Eigler]

Basile Starynkevitch  writes:

> [...]  If Ian's DWARF reader is simple enough (since suited for a
> single purpose), it might be helpful to avoid yet another external
> library dependency for GCC. [...]

OTOH, DWARF is not a stationary target, so one should consider the
benefits of offloading forseeable future maintenance too to specialist
F/OSS projects.

- FChE

Re: GCC stack backtraces

[Ian Lance Taylor]

On Wed, Aug 29, 2012 at 6:27 AM, Michael Matz  wrote:
>
> On Wed, 29 Aug 2012, Ian Lance Taylor wrote:
>
>> Does this seem like something we could usefully add to GCC?  Does
>> anybody see any big problems with it?
>
> Does it work without unwind tables?  I suspect it doesn't as it's using
> libgccs unwinder, so that would be a problem if we were to use it to
> generally replace our current non-backtrace based means.

This implementation requires unwind tables.  Since I wrote it
primarily for use in GCC, and since C++ requires unwind tables, and
for that matter so does the x86_64 ABI, I don't really see that as a
major issue.

In any case there is no reason to remove the current mechanisms.

Ian

Re: GCC stack backtraces

[Ian Lance Taylor]

On Wed, Aug 29, 2012 at 12:43 AM, Janne Blomqvist
 wrote:
> On Wed, Aug 29, 2012 at 10:22 AM, Ian Lance Taylor  wrote:
>> I've spent the last couple of days working on a stack backtrace library.
>>
>> It uses the GCC unwind interface to collect a stack trace, and parses
>> DWARF debug info to get file/line/function information.
> [snip]
>> I expect to use this code not just for GCC proper, but also for libgo
>> (currently libgo uses Go code to parse DWARF, but that is not very
>> satisfactory as that code is only available if it has been imported into
>> the program).  So I put it under a BSD license, although that is open
>> for discussion.  Also in case it finds more uses elsewhere I wrote it in
>> reasonably portable C rather than C++.
>>
>>
>> Does this seem like something we could usefully add to GCC?  Does
>> anybody see any big problems with it?
>
> I haven't looked at the code, but if it is async-signal-safe it could
> be interesting for gfortran. Currently in libgfortran we have a
> backtracing routine, originally written by FX Coudert IIRC, since
> rewritten by yours truly a few times, that uses _Unwind_Backtrace()
> from libgcc and then pipes the output via addr2line, if found. Since
> it's invoked from a signal handler when the program (user program, not
> the compiler!) crashes, it needs to be async-signal-safe. AFAIK the
> current implementation *should* fulfill that requirement. But
> something that would be async-signal-safe and won't need addr2line to
> get symbolic info would be a nice improvement, in particular since
> addr2line doesn't work on OSX, and all that piping stuff doesn't work
> on Windows.

I believe the unwinder proper is async signal safe--it just uses
_Unwind_Backtrace.

The DWARF reader calls malloc and is therefore not async-signal safe.
It would be difficult to write an efficient DWARF reader that does not
allocate any memory, and I'm not aware of any way to allocate memory
that is defined to be async-signal safe.  That said, as far as I know
mmap is async-signal safe in practice if not in theory, so one
approach would be  to do memory allocation using mmap.

Ian

Re: GCC stack backtraces

[H.J. Lu]

On Wed, Aug 29, 2012 at 9:21 AM, Ian Lance Taylor  wrote:
> On Wed, Aug 29, 2012 at 12:43 AM, Janne Blomqvist
>  wrote:
>> On Wed, Aug 29, 2012 at 10:22 AM, Ian Lance Taylor  wrote:
>>> I've spent the last couple of days working on a stack backtrace library.
>>>
>>> It uses the GCC unwind interface to collect a stack trace, and parses
>>> DWARF debug info to get file/line/function information.
>> [snip]
>>> I expect to use this code not just for GCC proper, but also for libgo
>>> (currently libgo uses Go code to parse DWARF, but that is not very
>>> satisfactory as that code is only available if it has been imported into
>>> the program).  So I put it under a BSD license, although that is open
>>> for discussion.  Also in case it finds more uses elsewhere I wrote it in
>>> reasonably portable C rather than C++.
>>>
>>>
>>> Does this seem like something we could usefully add to GCC?  Does
>>> anybody see any big problems with it?
>>
>> I haven't looked at the code, but if it is async-signal-safe it could
>> be interesting for gfortran. Currently in libgfortran we have a
>> backtracing routine, originally written by FX Coudert IIRC, since
>> rewritten by yours truly a few times, that uses _Unwind_Backtrace()
>> from libgcc and then pipes the output via addr2line, if found. Since
>> it's invoked from a signal handler when the program (user program, not
>> the compiler!) crashes, it needs to be async-signal-safe. AFAIK the
>> current implementation *should* fulfill that requirement. But
>> something that would be async-signal-safe and won't need addr2line to
>> get symbolic info would be a nice improvement, in particular since
>> addr2line doesn't work on OSX, and all that piping stuff doesn't work
>> on Windows.
>
> I believe the unwinder proper is async signal safe--it just uses
> _Unwind_Backtrace.
>
> The DWARF reader calls malloc and is therefore not async-signal safe.
> It would be difficult to write an efficient DWARF reader that does not
> allocate any memory, and I'm not aware of any way to allocate memory
> that is defined to be async-signal safe.  That said, as far as I know
> mmap is async-signal safe in practice if not in theory, so one
> approach would be  to do memory allocation using mmap.
>

Using mmap instead of malloc is a good idea.  It should fix:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724


-- 
H.J.

Re: GCC stack backtraces

[David Daney]

On 08/29/2012 12:43 AM, Janne Blomqvist wrote:

On Wed, Aug 29, 2012 at 10:22 AM, Ian Lance Taylor  wrote:

I've spent the last couple of days working on a stack backtrace library.

It uses the GCC unwind interface to collect a stack trace, and parses
DWARF debug info to get file/line/function information.

[snip]

I expect to use this code not just for GCC proper, but also for libgo
(currently libgo uses Go code to parse DWARF, but that is not very
satisfactory as that code is only available if it has been imported into
the program).  So I put it under a BSD license, although that is open
for discussion.  Also in case it finds more uses elsewhere I wrote it in
reasonably portable C rather than C++.


Does this seem like something we could usefully add to GCC?  Does
anybody see any big problems with it?


I haven't looked at the code, but if it is async-signal-safe it could
be interesting for gfortran. Currently in libgfortran we have a
backtracing routine, originally written by FX Coudert IIRC, since
rewritten by yours truly a few times, that uses _Unwind_Backtrace()
from libgcc and then pipes the output via addr2line, if found. Since
it's invoked from a signal handler when the program (user program, not
the compiler!) crashes, it needs to be async-signal-safe. AFAIK the
current implementation *should* fulfill that requirement. But
something that would be async-signal-safe and won't need addr2line to
get symbolic info would be a nice improvement,


libgcj also uses this technique.  If this were merged, it would be 
really nice to retrofit libgcj to use it as well.


Having this capability available from C and C++ code would also be 
really nice.  Several times in the past I have hacked together an 
unwinder by calling _Unwind_Backtrace(), and then decoded the traces 
off-line using addr2line.  An easy, low-overhead way to add 
function/line number information to a trace would be quite welcome.


I would almost say to put it in libgcc along side of 
_Unwind_Backtrace(), but that doesn't seem the proper place for it.  It 
would be very convenient though.



Thanks,
David Daney

Re: GCC stack backtraces

[Ian Lance Taylor]

On Wed, Aug 29, 2012 at 1:07 AM, Paweł Sikora  wrote:
> On Wednesday 29 of August 2012 00:22:55 Ian Lance Taylor wrote:
>> I've spent the last couple of days working on a stack backtrace library.
>>
>> It uses the GCC unwind interface to collect a stack trace, and parses
>> DWARF debug info to get file/line/function information.  (Of course it's
>> silly to write yet another DWARF reader, but I didn't find an existing
>> reader that seemed wholly suitable.)
>
> isn't the libdwarf a good enough for reading?
>
> http://reality.sgiweb.org/davea/dwarf.html

libdwarf is GPLv2, so it wouldn't work for libgo, which was one of my
goals.  Also, while I could certainly have missed something, libdwarf
seems to be designed to read through DWARF information, or to generate
it.  It doesn't seem to be designed to efficiently map PC addresses to
file/line information, which means reading just a subset of the
information, e.g., to pick up the name of an inlined function.

Ian

Re: GCC stack backtraces

[Toon Moene]

On 08/29/2012 06:21 PM, Ian Lance Taylor wrote:


The DWARF reader calls malloc and is therefore not async-signal safe.


It also is a problem if the crash in the program is due to overwriting 
the malloc heap administration (which easily occurs in Fortran if you 
overwrite bounds of allocatable arrays that can't be caught by 
bounds-check due to the wrong bounds being used inside a subroutine).


I have had Fortran program tracebacks (as described by Janne) hanging 
due to this, which is hard to work around (euphemism).


--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

Re: GCC stack backtraces

[Paweł Sikora]

On Wednesday 29 of August 2012 11:37:07 Ian Lance Taylor wrote:
> On Wed, Aug 29, 2012 at 1:07 AM, Paweł Sikora  wrote:
> > On Wednesday 29 of August 2012 00:22:55 Ian Lance Taylor wrote:
> >> I've spent the last couple of days working on a stack backtrace library.
> >>
> >> It uses the GCC unwind interface to collect a stack trace, and parses
> >> DWARF debug info to get file/line/function information.  (Of course it's
> >> silly to write yet another DWARF reader, but I didn't find an existing
> >> reader that seemed wholly suitable.)
> >
> > isn't the libdwarf a good enough for reading?
> >
> > http://reality.sgiweb.org/davea/dwarf.html
> 
> libdwarf is GPLv2, so it wouldn't work for libgo, which was one of my goals.

libdwarf is on lgpl, dwarfdump tools are on gpl.

Re: GCC stack backtraces

[Ian Lance Taylor]

On Wed, Aug 29, 2012 at 9:31 AM, H.J. Lu  wrote:
> On Wed, Aug 29, 2012 at 9:21 AM, Ian Lance Taylor  wrote:
>>
>> I believe the unwinder proper is async signal safe--it just uses
>> _Unwind_Backtrace.
>>
>> The DWARF reader calls malloc and is therefore not async-signal safe.
>> It would be difficult to write an efficient DWARF reader that does not
>> allocate any memory, and I'm not aware of any way to allocate memory
>> that is defined to be async-signal safe.  That said, as far as I know
>> mmap is async-signal safe in practice if not in theory, so one
>> approach would be  to do memory allocation using mmap.
>>
>
> Using mmap instead of malloc is a good idea.  It should fix:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724

I don't think that is a very interesting bug for GCC developers, since
it is only talking about unwinding on systems that do not support
dl_iterate_phdr with a linker that supports --eh-frame-hdr.  On the
systems most people use, the unwinder does not allocate.

Not that I'm opposed to fixing it, of course.

Ian

Re: GCC stack backtraces

[Ian Lance Taylor]

On Wed, Aug 29, 2012 at 11:45 AM, Paweł Sikora  wrote:
> On Wednesday 29 of August 2012 11:37:07 Ian Lance Taylor wrote:
>> On Wed, Aug 29, 2012 at 1:07 AM, Paweł Sikora  wrote:
>> > On Wednesday 29 of August 2012 00:22:55 Ian Lance Taylor wrote:
>> >> I've spent the last couple of days working on a stack backtrace library.
>> >>
>> >> It uses the GCC unwind interface to collect a stack trace, and parses
>> >> DWARF debug info to get file/line/function information.  (Of course it's
>> >> silly to write yet another DWARF reader, but I didn't find an existing
>> >> reader that seemed wholly suitable.)
>> >
>> > isn't the libdwarf a good enough for reading?
>> >
>> > http://reality.sgiweb.org/davea/dwarf.html
>>
>> libdwarf is GPLv2, so it wouldn't work for libgo, which was one of my goals.
>
> libdwarf is on lgpl, dwarfdump tools are on gpl.

Thanks for the correction.  In any case, I can't put LGPL code into
libgo either.

Ian

Re: detecting if cross-compiler (in plugin)?

[Ian Lance Taylor]

On Wed, Aug 29, 2012 at 1:59 AM, Basile Starynkevitch
 wrote:
>
> What is the simplest way, for a plugin (and also for a GCC branch),
> to detect if the compiler is straight or not (i.e. cross, that is
> target & host are different, or even canadian-cross).
>
> I was thinking of some macro in auto-host.h or other header.
>
> (MELT is, during its building procedure, testing itself by running
> a simple MELT pass on the MELT runtime. Obviously this step makes
> no sense for cross compilers, hence the question)

It sounds like what you want to know is not whether host != target,
but whether build != target.  Actually you may want to know whether
the compiler produces executables that run on the build system, but
that is more complicated still--e.g., a cross-compiler from x86_64 to
i386 GNU/Linux can produce executables that run on the build system
even though it is configured as a cross-compiler.

Unfortunately I don't know of any way to check within GCC whether
build == target.  It's not something that GCC generally cares about.

One imperfect thing you can test is whether CROSS_DIRECTORY_STRUCTURE
is defined.  That is true when host != target.

In general I would support having ways for plugins to detect this sort
of thing, perhaps simply by making the build, host, and target triplet
strings available to the plugin in some way.

Ian