From: Elena Zannoni <ezannoni@cygnus.com>
To: Jonathan Larmour <jlarmour@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: SH breakpoint problem
Date: Tue, 07 Aug 2001 07:26:00 -0000 [thread overview]
Message-ID: <15215.64646.329849.18396@krustylu.cygnus.com> (raw)
In-Reply-To: <3B6F5625.ADBD6F53@redhat.com>
Jonathan Larmour writes:
> I've been sanity checking both the GCC 3.0.1 candidate and the GDB 5.1
> candidate, and I've found an issue on the SH, which I'm debugging remotely.
> Setting a breakpoint on this simple function:
>
> void
> cyg_test_exit(void)
> {
> for(;;);
> }
>
> fails - it reports a SIGILL. I believe this is probably a watchdog timer.
> The problem is that, given the disassembly:
>
> Dump of assembler code for function cyg_test_exit:
> 0x800b130 <cyg_test_exit>: mov.l r14,@-r15
> 0x800b132 <cyg_test_exit+2>: mov r15,r14
> 0x800b134 <cyg_test_exit+4>: bra 0x800b134 <cyg_test_exit+4>
> 0x800b136 <cyg_test_exit+6>: nop
>
> GDB sets the breakpoint at 0x800b136, rather than 0x800b134. Tracing
> through GDB, I found after_prologue() in sh-tdep.c does:
>
> /* Get the line associated with FUNC_ADDR. */
> sal = find_pc_line (func_addr, 0);
>
> /* There are only two cases to consider. First, the end of the source
> line
> is within the function bounds. In that case we return the end of the
> source line. Second is the end of the source line extends beyond the
> bounds of the current function. We need to use the slow code to
> examine instructions in that case. */
> if (sal.end < func_end)
> return sal.end;
>
> The problem is, I believe, that the debug info is probably right and the
> end of the source line is indeed 0x800b136 (as is returned from
> find_pc_line) since the nop is in a delay slot, but it is mistaken to
> assume that is where the breakpoint should be set.
>
> But I don't know what way I should try to fix it. Matching instructions
> with delay slots like branches explicitly by reading from the target is my
> first thought but it seems awfully wasteful, and I'm sure there is received
> knowledge on this subject. So, what is it :-).
I should know, but I don't (I am the gdb sh person). :-(
What does gdb do with the same program against the simulator?
Elena
next prev parent reply other threads:[~2001-08-07 7:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-06 19:45 Jonathan Larmour
2001-08-07 5:53 ` Jonathan Larmour
2001-08-07 7:26 ` Elena Zannoni [this message]
2001-08-07 7:33 ` Jonathan Larmour
2001-08-07 7:54 ` Elena Zannoni
2001-08-07 8:05 ` Jonathan Larmour
2001-08-09 14:49 ` Andrew Cagney
2001-08-09 16:52 ` Jonathan Larmour
2001-08-09 18:05 ` Andrew Cagney
2001-08-10 14:24 ` Jonathan Larmour
2001-08-07 15:42 ` Kevin Buettner
2001-08-07 21:54 ` Alexandre Oliva
2001-08-07 22:46 ` Kevin Buettner
2001-08-09 12:48 ` Jonathan Larmour
2001-08-09 13:29 ` Kevin Buettner
2001-08-09 14:05 ` Jonathan Larmour
2001-08-09 14:28 ` Andrew Cagney
2001-08-09 14:57 ` Kevin Buettner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15215.64646.329849.18396@krustylu.cygnus.com \
--to=ezannoni@cygnus.com \
--cc=gdb@sources.redhat.com \
--cc=jlarmour@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox