From: "Terry Guo" <terry.guo@arm.com>
To: "'Pedro Alves'" <pedro@codesourcery.com>, <gdb-patches@sourceware.org>
Cc: "Richard Earnshaw" <Richard.Earnshaw@arm.com>,
"Yao Qi" <yao@codesourcery.com>
Subject: RE: [PATCH] Fix that different function breakpoints are set at same pc address (PR gdb/12703)
Date: Wed, 13 Jul 2011 13:21:00 -0000 [thread overview]
Message-ID: <000001cc4136$74ec62b0$5ec52810$@guo@arm.com> (raw)
In-Reply-To: <201107011046.36650.pedro@codesourcery.com>
Hi,
Sorry for bringing this topic back after so long time.
Recently I met a case which I think may have relation with
this topic. Please see my embedded comments and if I am wrong
please correct me.
> Indeed. Well, GDB is not a compiler; it is supposed to be able to
> debug buggy code. :-) Turning things upside down, the root question
> is
> whether there are valid cases where when setting a breakpoint
> at "foo", when GDB goes analysing the prologue, GDB should cross
> function boundaries into the next function, which would get
> broken by Terry's proposal. E.g., say, foo and bar get merged
> by some smart compiler/linker:
>
> foo:
> <nop>
> bar:
> <regular prologue>
> <body code>
>
> I guess setting a break on "foo" should set a breakpoint
> on "<body code>". Or (another user of prologue skipping,)
I have a bunch of interrupt response functions in my source whose layout looks like:
ext_isr_100:
nop
ext_isr_101:
nop
ext_isr_102:
nop
bar:
<regular prologue>
<body code>
If breakpoints of function ext_isr_100, ext_isr_101 and ext_isr_102 are all set on bar's
<body code>. Then I think I have no way to figure out which interrupt is trigged.
For this case, I still think it is better to set breakpoint inside the function body.
> stepping into a foo() call should only stop on "<body code>".
> Or, should GDB be conservative, and never cross the function
> body when skipping the prologue the hard way, and only
> cross it if debug info says so.
>
> --
> Pedro Alves
Best regards,
Terry
next prev parent reply other threads:[~2011-07-13 8:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-27 11:26 Terry Guo
2011-06-29 1:26 ` Terry Guo
2011-06-29 5:36 ` Yao Qi
2011-06-29 7:00 ` Terry Guo
2011-06-29 8:00 ` Yao Qi
2011-06-29 8:49 ` Terry Guo
[not found] ` <45520D6299C11E4588128526465332BB0D0C8B1246@SAROVARA.Asiapac.Arm.com>
2011-06-29 10:00 ` Yao Qi
2011-06-29 10:17 ` Terry Guo
2011-07-01 8:59 ` Richard Earnshaw
2011-07-01 9:47 ` Pedro Alves
2011-07-13 13:21 ` Terry Guo [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-06-24 2:31 Terry Guo
2011-06-24 3:55 ` Yao Qi
2011-06-24 8:59 ` Pedro Alves
2011-06-24 10:39 ` Yao Qi
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='000001cc4136$74ec62b0$5ec52810$@guo@arm.com' \
--to=terry.guo@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=pedro@codesourcery.com \
--cc=yao@codesourcery.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