Debugging frameless code

Debugging frameless code

[Nicolas.Thery]

Hi,

GDB documentation states that gdb has limited ability to deal with code
compiled without frame pointer.

Does this limitation applies to every version of gdb and every kind of
binary/debug format?

To be more precise, is it possible to dump stack backtrace for frameless
code using a recent version of gdb and elf/dwarf2 (and gcc as the
compiler)?

I've been told that dwarf2 includes information that can help a debugger in
such a case, but I don't know whether gcc actually emits these information
and whether gdb is able to use them.

Thanks in advance

Re: Debugging frameless code

[Kevin Buettner]

On Sep 28,  3:43pm, Nicolas.Thery@Symbian.com wrote:

> GDB documentation states that gdb has limited ability to deal with code
> compiled without frame pointer.
> 
> Does this limitation applies to every version of gdb and every kind of
> binary/debug format?

GDB does better on some targets than others.  At the moment, I don't
think it depends too much upon the debug format.  Most targets scan
the function prologue to learn about whether the function has a frame
pointer or not and also to learn where various registers are saved. 
Some are better at handling functions that don't have frame pointers
than others.

> To be more precise, is it possible to dump stack backtrace for frameless
> code using a recent version of gdb and elf/dwarf2 (and gcc as the
> compiler)?

In some cases, yes.  For example, I've been able to do this for
Linux/IA-64.  (But it's also the case that as the optimization gets
more aggressive, this could fail.)

Which target in particular were you wondering about?

> I've been told that dwarf2 includes information that can help a debugger in
> such a case, but I don't know whether gcc actually emits these information
> and whether gdb is able to use them.

I'll let someone who is more familiar with DWARF2 than myself answer
this.  I will note, however, that gdb's DWARF2 support is far from
complete and could certainly be made better.

Kevin

Re: Debugging frameless code

[Daniel Berlin]

> 
> I haven't tried frameless functions for ARM (and certainly not for
> THUMB).  However, I did commit the following change recently which
> does help gdb better deal with optimized code (the arm_scan_prologue
> bit):
> 

I can answer this question authoritatively. By default, on all platforms
but MIPS, gcc is not generating the information needed to get stack
backtraces in all cases, when we have no frame pointer. GCC *can* generate
the info, it's just only told to on MIPS. I've turned it on to play with
on BeOS, by #defining DWARF2_UNWIND_INFO in the beos-elf.h file in GCC,
and recompiling GCC.

However, GDB currently won't use this info in any case.
I've been reworking the dwarf2 reader, and i can add support for reading
the info, and even evaluating it, but we wouldn't be able to do anything
with it, without
modifying other parts of gdb to see if we were using dwarf2, and if we had
the call frame info, use it.
--Dan

Re: Debugging frameless code

[Peter Reilley]

I have been working in this area as well.   I am adding support for
the Macraigor Systems Kestrel for a number of processors including
ARM.   Since we are able to grab hold of the processor in any
state, the register contents might be garbage.   Particularly,
if the frame pointer is garbage then we take a JTAG bus error
when GDB de-references the frame pointer.   This causes
the ocd_open to fail.

The solution that I came up with is to set the FP to NULL in the
register cache.   I then test the pointer in the loop that walks
the frames.   If it is NULL then exit.   This allows the open to
succeed.

Later when the FP register is read and the garbage value is
de-referenced the JTAG bus error is handled properly.

I don't have a patch yet, there is still some work to be done.
Does this seem to be a reasonable approach.

I have the ARM and PowerPC working mostly.   There are
libraries and a driver available for Linux to driver parallel port
attached Kestrels.   I also have GDB for Ethernet attached
Kestrels for Linux and Solaris.

Thanks,
Pete.


-----Original Message-----
From: Kevin Buettner <kevinb@cygnus.com>
To: Nicolas.Thery@Symbian.com <Nicolas.Thery@Symbian.com>;
gdb@sources.redhat.com <gdb@sources.redhat.com>
Date: Friday, September 29, 2000 5:45 AM
Subject: Re: Debugging frameless code


>On Sep 29, 10:26am, Nicolas.Thery@Symbian.com wrote:
>
>> Kevin Buettner <kevinb@cygnus.com> wrote:
>>
>> >  >  To  be  more  precise,  is  it  possible  to dump stack backtrace
for
>> frameless
>> > > code using a recent version of gdb and elf/dwarf2 (and gcc as the
>> > > compiler)?
>> >
>> > In some cases, yes.  For example, I've been able to do this for
>> > Linux/IA-64.  (But it's also the case that as the optimization gets
>> > more aggressive, this could fail.)
>> >
>> > Which target in particular were you wondering about?
>>
>> Thanks for your answer.
>>
>> I'm interested in ARM/THUMB debugging.  Currently I use GDB 4.17 (from
>> Cygnus GNUPro 98r2) with PE-COFF/STABS.  With that configuration
backtrace
>> does not work if the involved functions are frameless.  I was wondering
>> whether the situation would be improved by using a more recent version of
>> GDB and/or ELF/DWARF.
>>
>> I looked at the ARM backtrace code in the GDB CVS repository a couple of
>> months ago and it seemed quite similar to GDB 4.17 but I may be wrong.
>
>I haven't tried frameless functions for ARM (and certainly not for
>THUMB).  However, I did commit the following change recently which
>does help gdb better deal with optimized code (the arm_scan_prologue
>bit):
>
>2000-09-05  Kevin Buettner  <kevinb@redhat.com>
>
> * config/arm/tm-linux.h (arm_linux_sigcontext_register_address,
> arm_linux_in_sigtramp): Declare.
> (IN_SIGTRAMP, SIGCONTEXT_REGISTER_ADDRESS): Define.
> * arm-tdep.c (SIGCONTEXT_REGISTER_ADDRESS): Define to be 0
> if not already defined by tm.h.
> (arm_scan_prologue): Don't assume that the prologue instructions
> will be in a contiguous clump.
> (arm_init_extra_frame_info): Add support for sigtramp frames.
> (arm_pc_is_thumb, arm_pc_is_thumb_dummy): Change type of
> `memaddr' from bfd_vma to CORE_ADDR.
> * arm-linux-tdep.c (gdbcore.h, frame.h): Include.
> (arm_pc_is_thumb): Declare.
> (arm_linux_skip_solib_resolver): Fix printf() statement.  [Which
> shouldn't be there anyway.]
> (ARM_LINUX_SIGRETURN_INSTR, ARM_LINUX_RT_SIGRETURN_INSTR): New
> defines.
> (arm_linux_in_sigtramp, arm_linux_sigcontext_register_address):
> New functions.
>
>You may want to try the current development sources and see how they
>work for you.
>
>Kevin
>

Re: Debugging frameless code

[Kevin Buettner]

On Sep 29, 10:26am, Nicolas.Thery@Symbian.com wrote:

> Kevin Buettner <kevinb@cygnus.com> wrote:
> 
> >  >  To  be  more  precise,  is  it  possible  to dump stack backtrace for
> frameless
> > > code using a recent version of gdb and elf/dwarf2 (and gcc as the
> > > compiler)?
> >
> > In some cases, yes.  For example, I've been able to do this for
> > Linux/IA-64.  (But it's also the case that as the optimization gets
> > more aggressive, this could fail.)
> >
> > Which target in particular were you wondering about?
> 
> Thanks for your answer.
> 
> I'm interested in ARM/THUMB debugging.  Currently I use GDB 4.17 (from
> Cygnus GNUPro 98r2) with PE-COFF/STABS.  With that configuration backtrace
> does not work if the involved functions are frameless.  I was wondering
> whether the situation would be improved by using a more recent version of
> GDB and/or ELF/DWARF.
> 
> I looked at the ARM backtrace code in the GDB CVS repository a couple of
> months ago and it seemed quite similar to GDB 4.17 but I may be wrong.

I haven't tried frameless functions for ARM (and certainly not for
THUMB).  However, I did commit the following change recently which
does help gdb better deal with optimized code (the arm_scan_prologue
bit):

2000-09-05  Kevin Buettner  <kevinb@redhat.com>

	* config/arm/tm-linux.h (arm_linux_sigcontext_register_address,
	arm_linux_in_sigtramp): Declare.
	(IN_SIGTRAMP, SIGCONTEXT_REGISTER_ADDRESS): Define.
	* arm-tdep.c (SIGCONTEXT_REGISTER_ADDRESS): Define to be 0
	if not already defined by tm.h.
	(arm_scan_prologue): Don't assume that the prologue instructions
	will be in a contiguous clump.
	(arm_init_extra_frame_info): Add support for sigtramp frames.
	(arm_pc_is_thumb, arm_pc_is_thumb_dummy): Change type of
	`memaddr' from bfd_vma to CORE_ADDR.
	* arm-linux-tdep.c (gdbcore.h, frame.h): Include.
	(arm_pc_is_thumb): Declare.
	(arm_linux_skip_solib_resolver): Fix printf() statement.  [Which
	shouldn't be there anyway.]
	(ARM_LINUX_SIGRETURN_INSTR, ARM_LINUX_RT_SIGRETURN_INSTR): New
	defines.
	(arm_linux_in_sigtramp, arm_linux_sigcontext_register_address):
	New functions.

You may want to try the current development sources and see how they
work for you.

Kevin

Re: Debugging frameless code

[Nicolas.Thery]

Kevin Buettner <kevinb@cygnus.com> wrote:

>  >  To  be  more  precise,  is  it  possible  to dump stack backtrace for
frameless
> > code using a recent version of gdb and elf/dwarf2 (and gcc as the
> > compiler)?
>
> In some cases, yes.  For example, I've been able to do this for
> Linux/IA-64.  (But it's also the case that as the optimization gets
> more aggressive, this could fail.)
>
> Which target in particular were you wondering about?

Thanks for your answer.

I'm interested in ARM/THUMB debugging.  Currently I use GDB 4.17 (from
Cygnus GNUPro 98r2) with PE-COFF/STABS.  With that configuration backtrace
does not work if the involved functions are frameless.  I was wondering
whether the situation would be improved by using a more recent version of
GDB and/or ELF/DWARF.

I looked at the ARM backtrace code in the GDB CVS repository a couple of
months ago and it seemed quite similar to GDB 4.17 but I may be wrong.

Nicolas