Re: Debugging frameless code

["Peter Reilley" <micrio at mv dot com>]

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
>