From: Pedro Alves <pedro@codesourcery.com>
To: Ross Morley <ross@tensilica.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [Fwd: Re: [PATCH] Program Breakpoints]
Date: Tue, 19 May 2009 20:21:00 -0000 [thread overview]
Message-ID: <200905192121.10299.pedro@codesourcery.com> (raw)
In-Reply-To: <4A130DE1.9060202@tensilica.com>
On Tuesday 19 May 2009 20:52:01, Ross Morley wrote:
> Thanks Pedro. This is the kind of feedback I was looking for
> in regard to effects on threads and other archs. I will have
> to go through your comments and think about those scenarios
> you mentioned with stepping. Before I do that I do want to
> clarify a couple of things for you.
>
> First, the intention is that a program breakpoint is not
> reported in the case of hitting a GDB breakpoint.
You mean, reported to the user, right? I agree. However,
the target will report to gdb a program breakpoint for
gdb breakpoints as well:
+ if (the_low_target.trap_size_at != NULL)
+ trap_size = (*the_low_target.trap_size_at) (stop_pc);
+ else if (the_low_target.breakpoint_at != NULL
+ && (*the_low_target.breakpoint_at) (stop_pc))
+ trap_size = the_low_target.breakpoint_len;
Only way to tell the difference is if there's a breakpoint
at PC in gdb's tables or not.
Hmm, isn't there an off-by-one error in the XCHAL_HAVE_BE
case here? :
+#if XCHAL_HAVE_BE
+ if (insn[1] == 0xd2 && (insn[2] & 0x0f) == 0x0f)
+#else
+ if (insn[0] == 0x2d && (insn[1] & 0xf0) == 0xf0)
+#endif
+ /* break.n s (density) */
> Test cases seem impossible to write completely generically
> because the test needs a target-specific break instruction.
> We have one (not in this patch) I could submit for Xtensa.
> It places 2 sizes of program breakpoints for Xtensa as follows:
> __asm__("break 7,15");
> __asm__("break.n 7");
> Is there a way to write a generic test with a program break?
I think you can do something reasonably generic enough by
passing "additional_flags=-DNOP=mysmallnopinsn -DBREAK_INSN1=foo -DBREAK_INSN2=bar"
to gdb_compile, and write the test in c with embedded asm, as:
int foo ()
{
NOP
NOP
BREAK_INSN1
jmphere:
NOP /* breakpoint here*/
NOP
BREAK_INSN1
NOP
goto jmphere;
}
etc, etc.
Then, the .exp file passes the appropriate defines/flags
based on target triplet.
if { ([istarget "xtensa*-*-*"] } {
additional_flags={-DNOP=mysmallnopinsn -DBREAK_INSN1="break 7,15" -DBREAK_INSN2="break.n 7"}
} else if { ([istarget "fooarch*-*-*"] } {
...
}
--
Pedro Alves
next prev parent reply other threads:[~2009-05-19 20:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-19 17:30 Ross Morley
2009-05-19 18:58 ` Pedro Alves
2009-05-19 19:53 ` Ross Morley
2009-05-19 20:21 ` Pedro Alves [this message]
2009-05-19 21:33 ` Ross Morley
2009-05-27 1:49 ` [PATCH] Program Breakpoints Ross Morley
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=200905192121.10299.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=ross@tensilica.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