Re: Helping out GDB

Re: Helping out GDB

[James L. Dein]

>  From gcc-return-18993-jdein=wrs.com@gcc.gnu.org Fri Jul 14 16:05 PDT 2000
>  Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
>  List-Unsubscribe: < mailto:gcc-unsubscribe-jdein=wrs.com@gcc.gnu.org >
>  List-Archive: < http://gcc.gnu.org/ml/gcc/ >
>  List-Post: < mailto:gcc@gcc.gnu.org >
>  List-Help: < http://egcs.cygnus.com/ml/ >
>  Delivered-To: mailing list gcc@gcc.gnu.org
>  Date: Sat, 15 Jul 2000 01:04:23 +0200
>  From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
>  To: jdein@windriver.com
>  CC: dberlin@redhat.com, dje@watson.ibm.com, gcc@gcc.gnu.org
>  Subject: Re: Helping out GDB
>  User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 
(i586-pc-linux-gnu) MULE/4.0 (HANANOEN)
>  MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko")
>  
>  > VxWorks requires 'gcc2_compiled.'.  When gcc3_compiled. comes out,
>  > it will need that too.
>  
>  Could you please be a bit more specific what it needs that for? I
>  thought about proposing a patch to remove this feature entirely. If it
>  is to stay, I think its applications will need to be documented, so
>  future maintainers can re-validate the rationale for having it.

Oh, well.  Your request-for-info has led to a furious :-) disucussion here, and 
it appears that `gcc2_compiled.' will not be an issue after all.  Feel free to 
nuke it.  Sorry about the red herring.

Our downloading tools sometimes use gcc_compiled. to identify the code as being 
built with GNU (rather than a proprietary compiler).

Jim Dein

>  Regards,
>  Martin
>  

Re: Helping out GDB

[Martin v. Loewis]

> VxWorks requires 'gcc2_compiled.'.  When gcc3_compiled. comes out,
> it will need that too.

Could you please be a bit more specific what it needs that for? I
thought about proposing a patch to remove this feature entirely. If it
is to stay, I think its applications will need to be documented, so
future maintainers can re-validate the rationale for having it.

Regards,
Martin

Re: Helping out GDB

[Martin v. Loewis]

> Is it the same for DWARF2 (I don't have a vtable thunks platform
> lying around, and don't remember what number to use with
> -fvtable-thunks).

Not being a debugger expert, I can't make out any sense of the numbers
being emitted. I see a string in the section .debug_info

	.byte	0x4
	.byte	0x1
	.byte	0x3
	.4byte	0x49
	.byte	0x3
	.string	"_vptr.X"

Since gcc never uses _vtpr.X itself, I wonder whether this could be a
bug, and really should be the symbol name of the vtable.

> Fer instance, how do i get the exception type being thrown, and
> where it was thrown from (I suppose i could always just look a few
> frames upwards to see where we called it from, or look at __eh_pc),
> from cp_push_exception?

Sure is. It helps enormously to see this code in action. For example,
given

void foo()
{
  throw 1;
}

gcc (-O2, on i586-pc-linux-gnu, with all labels removed) emits


	pushl $4
	call __eh_alloc  ; allocate four byte for the integer

	movl %eax,%ebx
	movl $1,(%ebx)   ; put the value in there
	addl $16,%esp
	addl $-4,%esp    ; adjust stack - 2.96 does better than that
	pushl $0         ; cleanup_fn, int has no dtor

	call __tfi       ; get int typeinfo pointer into eax
	pushl %eax       ; type
	pushl %ebx       ; value
	call __cp_push_exception  ; set type and value thread-safely
	call __throw              ; initiate unwinding

> > What exactly where those complaints?
> 
> That cp_push_exception/cp_pop_exception didn't exist, IIRC.

Yes, in gcc 2.8, egcs 1.0, and earlier, EH was not
thread-safe. cc1plus would directly modify global variables (__eh_pc
and friends). On such a system, you'd have to break on __throw, and
then look into these globals - or fail gracefully.

> I'm willing to tell these people to upgrade to a newer gcc if the
> exception interface is going to stay standard for a while.

The EH ABI of egcs 1.1 and gcc 2.95 will change in gcc 3 again, as
part of the new C++ ABI (which then is hopefully here to stay). The EH
part of it is specified at

http://reality.sgi.com/dehnert_engr/cxx/abi-eh.html

i.e. the function initiating an unwind is _Unwind_RaiseException.

However, this isn't implemented, yet, and it is not clear (to me, at
least) whether this part of the ABI is limited to IA64, or can be
extended beyond this architecture.

> However, we don't parse/use the frame unwinding information.
> But it appears we don't need to.

Not so sure about that. In single stepping mode, I always wanted gdb
to step from the throw to the next cleanup, or the next catch block.
Is that implemented in gdb? One approach would be to mentally unwind
yourself, and then set an automatic breakpoint into the target unwind
operation.

Regards,
Martin

Re: Helping out GDB

[Martin v. Loewis]

> > Why is that? If the symbols start with __vt_, it's vtable thunks; if
> > they start with __vt., it's old-style vtables. Is that difficult to
> > tell apart? 
> 
> Last time I looked, whether "." was a valid character for an object format 
> was a back-end choice (the assembler may not grok it).  In such cases, 
> either "$" or, in the worst case, "_" is substituted instead.  So in 
> general: No, it isn't enough.

There are three possibilites:
                     thunks         nothunks
$ in label           __vt_          _vt$
. in label           __vt_          _vt.
neither/nor          __vt_          _vt_

So it's actually the "__vt" prefix that allows to reliably tell apart
thunks vs nothunks.

Regards,
Martin

Re: Helping out GDB

[Daniel Berlin+list.gcc]

"Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> writes:

> > Because in the debug info, they are always specified a different way
> > (which is a *good thing*).
> > So now i have to go hunting through the minimal symbols, just to see
> > if something was a vtable thunk or not.
> 
> I don't follow. Given
> 
> struct X{
>   virtual void foo();
> };
> 
> void X::foo(){}
> 
> when compiled with -g, I get a line
> 
> .stabs "__vt_1X:G(0,32)=ar(0,1);0;3;(0,22)",32,0,3,0
> 
> Right here, you can see it's vtable thunks. Is this not debug info?

Yes, it is.
Is it the same for DWARF2 (I don't have a vtable thunks platform lying around, and don't remember what number to use with -fvtable-thunks).

> 
> > > Sure you do. Mangled symbols of the new ABI all start with _Z (except
> > > for the extern "C" ones, of course); there won't be any __vt symbols.
> > > If that is not enough identification, I could also give you a list of
> > > functions that will be there.
> >
> > And you can guarantee me this won't change for a release (IE 3.x)?
> 
> For the new ABI ones, yes, I can.

Works for me.
> 
> > I know quite a few people who want to break when the "blah"
> > exception is *thrown*.
> 
> I see. Even though there is more than one function that is used for
> this purpose, there actually is a limited number of them. So would it
> help if the gdb team is informed whenever something changes here? 

Yes, that would be great.
> We
> could certainly put a comment in the code saying "please send a
> message to <gdb@somewhere>" when you change the interface in this
> file.

That was the main worry, that it would break without us finding out until way too late.

> 
> > > For example, __cp_push_exception indeed has all the information you
> > > want.
> > 
> > Not in a form i can easily parse.
> 
> Why is that? I think the arguments to __cp_push_exception are
> well-specified.

I meant parse as in "extract info from", not understand what they mean.
Fer instance, how do i get the exception type being thrown, and where it was thrown from (I suppose i could always just look a few frames upwards to see where we called it from, or look at __eh_pc), from cp_push_exception?
IE is the type parameter a pointer to RTTI info, etc?

> 
> > And then, i got complaints from people who have platforms still
> > using other forms of exceptions.
> 
> What exactly where those complaints?

That cp_push_exception/cp_pop_exception didn't exist, IIRC.
I could be wrong, of course, my memory ain't so good anymore.
I'm willing to tell these people to upgrade to a newer gcc if the exception interface is going to stay standard for a while. 

> 
> > I'm perfectly willing to put the time and effort into writing
> > something than can parse the dwarf2 info being used for exception
> > handling, if I know that this is going to be the way exceptions are
> > done from now on.
> 
> If you want to break when the "blah" exception is *thrown*, you don't
> need to know anything about dwarf2.

Yeah, just realized that.
>  However, given that DWARF2 is a
> format of debugging information, it may be a good idea if the debugger
> supported it, anyway :-)
It already does.
However, we don't parse/use the frame unwinding information.
But it appears we don't need to.

> 
> Regards,
> Martin

Re: Helping out GDB

[James L. Dein]

>  From gcc-return-18847-jdein=wrs.com@gcc.gnu.org Wed Jul 12 12:37 PDT 2000
>  Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
>  List-Unsubscribe: < mailto:gcc-unsubscribe-jdein=wrs.com@gcc.gnu.org >
>  List-Archive: < http://gcc.gnu.org/ml/gcc/ >
>  List-Post: < mailto:gcc@gcc.gnu.org >
>  List-Help: < http://egcs.cygnus.com/ml/ >
>  Delivered-To: mailing list gcc@gcc.gnu.org
>  To: dberlin@redhat.com
>  cc: gcc@gcc.gnu.org
>  Subject: Re: Helping out GDB
>  Date: Wed, 12 Jul 2000 15:35:37 -0400
>  From: David Edelsohn <dje@watson.ibm.com>
>  
>  	The version of GCC implementing the new ABI is going to be
>  gcc-3.0.  I would expect that the symbol "gcc2_compiled." should be
>  changed to "gcc3_compiled."  Do any applications rely upon the symbol
>  "gcc2_compiled." other than GDB?  GDB could detect "gcc3_compiled." to
>  flag the current use of "gcc2_compiled." and the new C++ ABI.

VxWorks requires 'gcc2_compiled.'.  When gcc3_compiled. comes out, it will need 
that too.

Jim Dein

>  
>  	Let me guess: We are going to need to emit both "gcc2_compiled."
>  and "gcc3_compiled." for backwards compatibility with GDB instead of
>  updating the symbol atomically.  At least that gives us another "bit" when
>  "gcc3_compiled." symbols exists and "gcc2_compiled." symbol eventually is
>  removed (:^).
>  
>  David

Re: Helping out GDB

[Russell Browne]

> 
> > I know quite a few people who want to break when the "blah"
> > exception is *thrown*.
> 
> I see. Even though there is more than one function that is used for
> this purpose, there actually is a limited number of them. So would it
> help if the gdb team is informed whenever something changes here? We
> could certainly put a comment in the code saying "please send a
> message to <gdb@somewhere>" when you change the interface in this
> file.
> 

I like the mail idea, but gdb is not the only debugger that tries to
cope with gcc.  If it were gcc_debuggers@somewhere, or gcc_gdb@somewhere,
in any event a mailing list for debugger writers who want to be
informed when the debugger interface to gcc changes.

Russ Browne
Aplied MicroSystems Corp.

Re: Helping out GDB

[Jeffrey A Law]

  In message < 200007141055.LAA01873@cam-mail2.cambridge.arm.com >you write:
  > 
  > law@cygnus.com said:
  > > I would think we could figure out the EH model by looking at what
  > > sections exist in the executable -- don't dwarf2 EH tables show up in
  > > their own special section? 
  > 
  > Not in a.out.  They are just part of the text segment.
Good point.  

So what kind of EH model is being used probably belongs in whatever
magic debug record we create.

jeff

Re: Helping out GDB

[Richard Earnshaw]

martin@loewis.home.cs.tu-berlin.de said:
> Why is that? If the symbols start with __vt_, it's vtable thunks; if
> they start with __vt., it's old-style vtables. Is that difficult to
> tell apart? 

Last time I looked, whether "." was a valid character for an object format 
was a back-end choice (the assembler may not grok it).  In such cases, 
either "$" or, in the worst case, "_" is substituted instead.  So in 
general: No, it isn't enough.

R.

Re: Helping out GDB

[Richard Earnshaw]

law@cygnus.com said:
> I would think we could figure out the EH model by looking at what
> sections exist in the executable -- don't dwarf2 EH tables show up in
> their own special section? 

Not in a.out.  They are just part of the text segment.

R.

Re: Helping out GDB

[Martin v. Loewis]

> Because in the debug info, they are always specified a different way
> (which is a *good thing*).
> So now i have to go hunting through the minimal symbols, just to see
> if something was a vtable thunk or not.

I don't follow. Given

struct X{
  virtual void foo();
};

void X::foo(){}

when compiled with -g, I get a line

.stabs "__vt_1X:G(0,32)=ar(0,1);0;3;(0,22)",32,0,3,0

Right here, you can see it's vtable thunks. Is this not debug info?

> > Sure you do. Mangled symbols of the new ABI all start with _Z (except
> > for the extern "C" ones, of course); there won't be any __vt symbols.
> > If that is not enough identification, I could also give you a list of
> > functions that will be there.
>
> And you can guarantee me this won't change for a release (IE 3.x)?

For the new ABI ones, yes, I can.

> I know quite a few people who want to break when the "blah"
> exception is *thrown*.

I see. Even though there is more than one function that is used for
this purpose, there actually is a limited number of them. So would it
help if the gdb team is informed whenever something changes here? We
could certainly put a comment in the code saying "please send a
message to <gdb@somewhere>" when you change the interface in this
file.

> > For example, __cp_push_exception indeed has all the information you
> > want.
> 
> Not in a form i can easily parse.

Why is that? I think the arguments to __cp_push_exception are
well-specified.

> And then, i got complaints from people who have platforms still
> using other forms of exceptions.

What exactly where those complaints?

> I'm perfectly willing to put the time and effort into writing
> something than can parse the dwarf2 info being used for exception
> handling, if I know that this is going to be the way exceptions are
> done from now on.

If you want to break when the "blah" exception is *thrown*, you don't
need to know anything about dwarf2. However, given that DWARF2 is a
format of debugging information, it may be a good idea if the debugger
supported it, anyway :-)

Regards,
Martin

Re: Helping out GDB

[Daniel Berlin+list.gcc]

"Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> writes:

> > As the C++ maintainer for GDB, I run into a lot of fun problems
> > where g++ isn't providing info we need.
> 
> While I strongly sympathize with the need to support gdb as good as
> possible, I can't see some of the problems you have.
> 
> > First and formost, for the old ABI, i have no way to detect what
> > kind of vtable thunks the platform is using, or lack thereof.
> 
> Why is that? If the symbols start with __vt_, it's vtable thunks; if
> they start with __vt., it's old-style vtables. Is that difficult to
> tell apart?

Yes.
Because in the debug info, they are always specified a different way (which is a *good thing*).
So now i have to go hunting through the minimal symbols, just to see if something was a vtable thunk or not.
This is a very expensive (time wise) idea in GDB.


> 
> > I have no way to tell whether something was compiled with the new or
> > old abi.
> 
> Sure you do. Mangled symbols of the new ABI all start with _Z (except
> for the extern "C" ones, of course); there won't be any __vt symbols.
> If that is not enough identification, I could also give you a list of
> functions that will be there.

And you can guarantee me this won't change for a release (IE 3.x)?
I don't want to run into the same problem people did when the solution was gcc2_compiled.

> 
> > That's just a bad hack because gcc isn't telling us what we need to
> > know.
> 
> If the approaches above don't work, please elaborate what problems
> they cause.

> 
> > It would be nice if GCC, like a few other compilers, provided a
> > callback so that I could say "when you get an exception in the
> > program, call this routine", and it would call the callback with a
> > few key parameters that i could use to tell what was thrown/caught
> > and where.
> 
> I'm not sure I understand this request. First, are you aware of
> __unwinding_cleanup? One problem with debugging exceptions is that it
> is ok for an exception to occur as long as it is going to be caught,
> so in a debugger, I'd like to break only if an exception is thrown
> that won't be caught; this is what __unwinding_cleanup is for.

I know quite a few people who want to break when the "blah" exception is *thrown*.
__unwinding_cleanup doesn't let me do that.

> 
> I can't see what the callback routine would achieve. For C++ alone,
> there are different ways to initiate stack unwinding, specifically
> throw <value>; and throw;. They require different entries into the
> run-time system, and likely would also require different callbacks.
No, they wouldn't.
HP, for instance, notifies GDB of all throws and catches with one callback, and provides sufficient information in the arguments of the callback to do all of this.

> For example, __cp_push_exception indeed has all the information you
> want.

Not in a form i can easily parse.
I tried before.
And then, i got complaints from people who have platforms still using other forms of exceptions.

I'm perfectly willing to put the time and effort into writing something than can parse the dwarf2 info being used for exception handling, if I know that this is going to be the way exceptions are done from now on.

> 
> > A callback would also remove the problem of their being so many
> > different implementations of exception handling, since GDB would no
> > longer have to care about how it was implemented.
> 
> Can you propose a specific ABI that you want to use. I have a hard
> time guessing what the requirements should be.
> 
Sure, i'd be happy to.
Give me a few days.

> Regards,
> Martin

Re: Helping out GDB

[Martin v. Loewis]

> As the C++ maintainer for GDB, I run into a lot of fun problems
> where g++ isn't providing info we need.

While I strongly sympathize with the need to support gdb as good as
possible, I can't see some of the problems you have.

> First and formost, for the old ABI, i have no way to detect what
> kind of vtable thunks the platform is using, or lack thereof.

Why is that? If the symbols start with __vt_, it's vtable thunks; if
they start with __vt., it's old-style vtables. Is that difficult to
tell apart?

> I have no way to tell whether something was compiled with the new or
> old abi.

Sure you do. Mangled symbols of the new ABI all start with _Z (except
for the extern "C" ones, of course); there won't be any __vt symbols.
If that is not enough identification, I could also give you a list of
functions that will be there.

> That's just a bad hack because gcc isn't telling us what we need to
> know.

If the approaches above don't work, please elaborate what problems
they cause.

> It would be nice if GCC, like a few other compilers, provided a
> callback so that I could say "when you get an exception in the
> program, call this routine", and it would call the callback with a
> few key parameters that i could use to tell what was thrown/caught
> and where.

I'm not sure I understand this request. First, are you aware of
__unwinding_cleanup? One problem with debugging exceptions is that it
is ok for an exception to occur as long as it is going to be caught,
so in a debugger, I'd like to break only if an exception is thrown
that won't be caught; this is what __unwinding_cleanup is for.

I can't see what the callback routine would achieve. For C++ alone,
there are different ways to initiate stack unwinding, specifically
throw <value>; and throw;. They require different entries into the
run-time system, and likely would also require different callbacks.
For example, __cp_push_exception indeed has all the information you
want.

> A callback would also remove the problem of their being so many
> different implementations of exception handling, since GDB would no
> longer have to care about how it was implemented.

Can you propose a specific ABI that you want to use. I have a hard
time guessing what the requirements should be.

Regards,
Martin

Re: Helping out GDB

[Jeffrey A Law]

  In message < m2d7kj6qu9.fsf@localhost.localdomain >you write:
  > I think gcc2_compiled is a hack as is.
Agreed.

  > Can't you just put the compile flags or feature flags in a string and inclu
  > de that, so i can see if it says "GCC 3.0, new-abi, DWARF2 based exceptions
  > ", or some such?
Well, I'd be more interested in designing some way to pass the information
you need in a structured way rather than as a bunch of hacks.  For example
we have ways to pass around ABI/ISA information in most object formats
now, that can be used to include "gcc/g++ ABI 3.0" instead of just
"mips o32, mips n32, etc etc"

I would think we could figure out the EH model by looking at what
sections exist in the executable -- don't dwarf2 EH tables show up in
their own special section?

  > Nothing in GDB actually depends on gcc2_compiled being there.
Right.  And I think that's the way it should stay :-)


  >  People before
  >  i became C++ maintainer gave up trying to detect the variations, and as a 
  > result, gcc2_compiled is never actually used right now (save one place, i b
  > elieve, but it's not even exported from the file it's set in anymore).
Right.  Instead of looking for a magic symbol, we need a structured way to
say "this program has the following features".  ie, describe the things
the debugger cares about rather than "I happened to compile this with compiler
xyz and hope the debugger figures out what it means".

It's not unlike how we deal with host specific issues -- we write autoconf
tests to look for specific features of the host rather than trying to
guess that hpux10.20 has a weird mmap, but hpux11.00 does it right, or 
whatever.

Jeff

Re: Helping out GDB

[Jim Wilson]

In article < 20000712134729R.mitchell@codesourcery.com > you write:
>Other tools depend on this being set.  The examples I know of our
>non-GNU tools, so we may or may not care, but some people will
>definitely complain if we remove this.

There are other tools that try to use gcc2_compiled, but they are all
misguided.  The change from gcc2 to gcc3 would be a good chance to drop this
historical baggage.

The gcc2_compiled symbol was originally emitted for the debugger.
Unfortunately there were so many practical problems with using it that
it was never reliable, and gdb had to stop using it.  It has been so long
since this issue was discussed that I don't remember all of the details.
I just remember that the problems were serious and intractable.

It is still useful for gdb to know whether code was gcc compiled or not, but
it doesn't get this info by looking at the symbol table, it gets it from
the debug info.  We already emit a gcc2_compiled. stab for gdb.  Ses
ASM_IDENTIFY_GCC_AFTER_SOURCE in config/dbxelf.h.  For dwarf and dwarf2
we emit this info in the producer string.  That only leaves sdb/coff,
and that format is hopeless anyways, so we don't care.

Some systems can't support the gcc2_compiled symbol.  Irix for instance.
The only thing that the Irix assembler allows in the text section is
well formed functions.  It doesn't allow naked labels.  Thus the irix
configurations don't emit the gcc2_compiled symbol.  There are other
targets that disable the gcc2_compiled symbol for other reasons.

The gcc2_compiled symbol can interfere with profilers.  It used to be that
you could run gprof and it would tell you that X% of the time was spent
in gcc2_compiled.  That is because the output looked like gcc2_compiled
was the name of the first function.  We fixed that by emitting a nop after
the gcc2_compiled label.  But that creates yet another problem, it makes
the code bigger, 4 bytes per module for a typical RISC.  This size increase
is a problem for some people, particularly people using gcc for embedded
development.

If it is necessary to keep the symbol for some reason, I'd suggest having
the default be to not emit the symbol.  Those targets that really want it
can re-enable it, but it will be off for most targets which is the best
choice.

Jim

Re: Helping out GDB

[Daniel Berlin+list.gcc]

Mark Mitchell <mark@codesourcery.com> writes:

>     Daniel> No, we can't.  This assumes nobody will try to use gcc 3.0
>     Daniel> + the old ABI for compatibility reasons (yes, i know it's
>     Daniel> going to be removed).
> 
> This just won't be possible.  The code for the old ABI will be gone by
> then.

Can you guarantee me the exception handling mechanism will be the same across all platforms, etc?
If so, feel free to just have a gcc3_compiled.
Otherwise, I need something a little better.
I don't want to run into what we have now, again.

> 
>     >> At least that gives us another "bit" when "gcc3_compiled."
>     >> symbols exists and "gcc2_compiled." symbol eventually is
>     >> removed (:^).
>     >> 
> 
>     Daniel> Feel free to remove it now, i grepped the sources, nothing
>     Daniel> uses it.
> 
> Other tools depend on this being set.  The examples I know of our
> non-GNU tools, so we may or may not care, but some people will
> definitely complain if we remove this.

Fine by me, but don't keep it on GDB's account.
:)
--Dan

Re: Helping out GDB

[Mark Mitchell]

>>>>> "Daniel" == Daniel Berlin+list gcc <dberlin@redhat.com> writes:

    Daniel> David Edelsohn <dje@watson.ibm.com> writes:

    >> The version of GCC implementing the new ABI is going to be
    >> gcc-3.0.  I would expect that the symbol "gcc2_compiled."
    >> should be changed to "gcc3_compiled."  Do any applications rely
    >> upon the symbol "gcc2_compiled." other than GDB?  GDB could
    >> detect "gcc3_compiled." to flag the current use of
    >> "gcc2_compiled." and the new C++ ABI.

    Daniel> No, we can't.  This assumes nobody will try to use gcc 3.0
    Daniel> + the old ABI for compatibility reasons (yes, i know it's
    Daniel> going to be removed).

This just won't be possible.  The code for the old ABI will be gone by
then.

    >> At least that gives us another "bit" when "gcc3_compiled."
    >> symbols exists and "gcc2_compiled." symbol eventually is
    >> removed (:^).
    >> 

    Daniel> Feel free to remove it now, i grepped the sources, nothing
    Daniel> uses it.

Other tools depend on this being set.  The examples I know of our
non-GNU tools, so we may or may not care, but some people will
definitely complain if we remove this.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Helping out GDB

[Daniel Berlin+list.gcc]

David Edelsohn <dje@watson.ibm.com> writes:

> 	The version of GCC implementing the new ABI is going to be
> gcc-3.0.  I would expect that the symbol "gcc2_compiled." should be
> changed to "gcc3_compiled."  Do any applications rely upon the symbol
> "gcc2_compiled." other than GDB?  GDB could detect "gcc3_compiled." to
> flag the current use of "gcc2_compiled." and the new C++ ABI.

No, we can't.
This assumes nobody will try to use gcc 3.0 + the old ABI for compatibility reasons (yes, i know it's going to be removed).
And what happens when you guys change something that i need to handle differently in gcc 3.1.

I think gcc2_compiled is a hack as is.
Can't you just put the compile flags or feature flags in a string and include that, so i can see if it says "GCC 3.0, new-abi, DWARF2 based exceptions", or some such?

I have a problem with assuming a version means features.
> 
> 	Let me guess: We are going to need to emit both "gcc2_compiled."
> and "gcc3_compiled." for backwards compatibility with GDB instead of
> updating the symbol atomically.
Why would this be true?
Nothing in GDB actually depends on gcc2_compiled being there. People before i became C++ maintainer gave up trying to detect the variations, and as a result, gcc2_compiled is never actually used right now (save one place, i believe, but it's not even exported from the file it's set in anymore).


>  At least that gives us another "bit" when
> "gcc3_compiled." symbols exists and "gcc2_compiled." symbol eventually is
> removed (:^).
> 
Feel free to remove it now, i grepped the sources, nothing uses it.

> David

Re: Helping out GDB

[David Edelsohn]

	The version of GCC implementing the new ABI is going to be
gcc-3.0.  I would expect that the symbol "gcc2_compiled." should be
changed to "gcc3_compiled."  Do any applications rely upon the symbol
"gcc2_compiled." other than GDB?  GDB could detect "gcc3_compiled." to
flag the current use of "gcc2_compiled." and the new C++ ABI.

	Let me guess: We are going to need to emit both "gcc2_compiled."
and "gcc3_compiled." for backwards compatibility with GDB instead of
updating the symbol atomically.  At least that gives us another "bit" when
"gcc3_compiled." symbols exists and "gcc2_compiled." symbol eventually is
removed (:^).

David

Helping out GDB

[Daniel Berlin+list.gcc]

As the C++ maintainer for GDB, I run into a lot of fun problems where g++ isn't providing info we need.
And with the new-abi, unless somebody does something, it's only going to get worse.
First and formost, for the old ABI, i have no way to detect what kind of vtable thunks the platform is using, or lack thereof.

Which isn't so bad, we've survived so far by trying it one way, and if doesn't work, trying it the other (which is less than optimal).

Now, with the new-abi coming, another problem is coming up.
I have no way to tell whether something was compiled with the new or old abi.

Can someone please add a symbol,like the gcc2_compiled symbol, that says "this was compiled with the new abi"?
I really can't support all the variants of the old abi+vtable thunks, as well as the new abi, by trying all of them until something works.
That's just a bad hack because gcc isn't telling us what we need to know.


While on the subject of helping GDB with C++ debugging, i've been working on making GDB support catching catches/throws.
It already works for any catch/throw, but once again, since there are a myriad of exception types support by gcc, with no way to tell them apart, I can't do anything more than this simple feature, because the names of the symbols i need to lookup, and where they are in relation to the actual throw/catch that was done, always seems to change.

It would be nice if GCC, like a few other compilers, provided a callback so that I could say "when you get an exception in the program, call this routine", and it would call the callback with a few key parameters that i could use to tell what was thrown/caught and where.
As long as exceptions were thread-safe, so would be doing a callback.
Any other way of providing GDB info about catches/throws is also acceptable, though it would be nice to be able to catch catches/throws of specific exception types, and it seems hard to do this without a callback.
A callback would also remove the problem of their being so many different implementations of exception handling, since GDB would no longer have to care about how it was implemented.



Thanks,
Dan