Re: Debugging frameless code

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

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
From micrio@mv.com Fri Sep 29 11:58:00 2000
From: "Peter Reilley" <micrio@mv.com>
To: <gdb@sources.redhat.com>
Subject: Re: Debugging frameless code
Date: Fri, 29 Sep 2000 11:58:00 -0000
Message-id: <004601c02a47$40c01a70$05d145cc@ppro>
X-SW-Source: 2000-09/msg00157.html
Content-length: 3584

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
>

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