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