RE: Strange behaviour in nexti with new architecture

["Anthony Berent" <Anthony dot Berent at arm dot com>]

Ramana,

Many thanks, this gave me the clue I needed. It turned out that there were a
number of problems in the DWARF call frame information causing this, but
none in gdb itself.

- Anthony

-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf
Of Ramana Radhakrishnan
Sent: 21 April 2009 13:06
To: Anthony Berent
Cc: gdb@sourceware.org
Subject: Re: Strange behaviour in nexti with new architecture

On Tue, Apr 21, 2009 at 12:36 PM, Anthony Berent <anthony.berent@arm.com>
wrote:
> Hi,
>
> I am creating a gdb architecture definition for an ARM data engine (a very
> different architecture from the ARM processor architecture). Much of it is
> now working, but I am finding the "n" and "ni" commands are failing to
stop
> at the function return point. ?Looking at the output of "set debug infrun
1"
> (see below), it seems that gdb is correctly setting and hitting the
> breakpoint on the return address, but is then deciding that it hasn't
> finished. I would welcome any suggestions on what might cause this
problem.
>
> My current codebase is based on the content of the CVS repository,
although
> it is probably a couple of months since I did an update and merged in the
> latest CVS changes.
>
> - Anthony
>
> The following is a log of my last test run, with comments added:
>
> GNU gdb (GDB) 6.8.50.20090224-cvs
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. ?Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf".
> <---- Actually multiple targets, uses target description from stub to
switch
> to data engine target.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> (gdb) sym ~/workspace/detest11/AR1DPU/fw/ode_hacked.elf
> Reading symbols from
> /home/aberent/workspace/detest11/AR1DPU/fw/ode_hacked.elf...done.
> (gdb) dir ~/workspace/detest11/AR1DPU
> Source directories searched:
> /home/aberent/workspace/detest11/AR1DPU:$cdir:$cwd
> (gdb) target remote localhost:10000
> Remote debugging using localhost:10000
> fact_10 () at /home/aberent/workspace/detest11/AR1DPU/../src.cxx:10
> 10 ? ? ?int fact_10(int i) {
> Current language: ?auto; currently c++
> (gdb) b *0x2a8 <--------------- This is the address of the function call
> Breakpoint 1 at 0x2a8: file
> /home/aberent/workspace/detest11/AR1DPU/../src.cxx, line 14.
> (gdb) c
> Continuing.
> Can't send signals to this remote system. ?SIGABRT not sent.
>
> Breakpoint 1, fact_10 ()
> ? ?at /home/aberent/workspace/detest11/AR1DPU/../src.cxx:14
> 14 ? ? ? ? ? ?mp = mult(result, i--, mp);
> (gdb) set debug infrun
> Argument required (integer to set it to.).
> (gdb) set debug infrun 1
> (gdb) ni ?<----------------- Should step to return address of function.
> infrun: clear_proceed_status_thread (Thread <main>)
> infrun: proceed (addr=0xffffffff, signal=144, step=1)
> infrun: resume (step=1, signal=0), trap_expected=1
> infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
> infrun: target_wait (-1, status) = 42000, status->kind = stopped, signal =
> SIGTRAP
> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x438 ?<----------------- This has correctly stepped
into
> the function.
> infrun: stepped into subroutine
> infrun: inserting step-resume breakpoint at 0x2b8 ?<------------ This is
the
> correct return address
> infrun: resume (step=0, signal=0), trap_expected=0 <------------ Ok
> infrun: prepare_to_wait
> infrun: target_wait (-1, status) = 42000, status->kind = stopped, signal =
> SIGTRAP
> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x2b8 ? <---------------- It has now stopped at the
return
> address. This should complete the "ni" command.
> infrun: BPSTAT_WHAT_SINGLE

Shouldn't this be BPSTAT_WHAT_STEP_RESUME ? That is the difference.
trying it out on a more recent version on arm-*-eabi + a simulator
target, I see a BPSTAT_WHAT_STEP_RESUME and not BPSTAT_WHAT_SINGLE.

infrun: clear_proceed_status_thread (Thread <main>)
infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1)
infrun: resume (step=1, signal=0), trap_expected=0
infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
infrun: target_wait (-1, status) =
infrun:   42000 [Thread <main>],
infrun:   status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x81c0
infrun: stepped into subroutine
infrun: inserting step-resume breakpoint at 0x8224
infrun: resume (step=0, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun:   42000 [Thread <main>],
infrun:   status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x8224
infrun: BPSTAT_WHAT_STEP_RESUME *****
infrun: stepi/nexti
infrun: stop_stepping



cheers
Ramana

> infrun: step-resume breakpoint is inserted
> infrun: resume (step=1, signal=0), trap_expected=1 <---------*** Why is it
> resuming again? It should have finished. ***
> infrun: prepare_to_wait
> infrun: target_wait (-1, status) = 42000, status->kind = stopped, signal =
> SIGTRAP
> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x2c8
> infrun: step-resume breakpoint is inserted
> infrun: resume (step=0, signal=0), trap_expected=0
> infrun: prepare_to_wait
> infrun: target_wait (-1, status) = 42000, status->kind = stopped, signal =
> SIGTRAP
> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x2a8 ?<----------------- Finally stops back at the
> original breakpoint, after going round the main loop of my test.
> infrun: BPSTAT_WHAT_STOP_NOISY
> infrun: stop_stepping
>
> Breakpoint 1, fact_10 ()
> ? ?at /home/aberent/workspace/detest11/AR1DPU/../src.cxx:14
> 14 ? ? ? ? ? ?mp = mult(result, i--, mp);
> (gdb)
>
>
>
>