This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: [ARM] "svc" insn check at irrelevant address in ARM unwind info sniffer
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, gdb-patches at sourceware dot org
- Date: Thu, 19 Nov 2015 14:45:17 +0000
- Subject: Re: RFA: [ARM] "svc" insn check at irrelevant address in ARM unwind info sniffer
- Authentication-results: sourceware.org; auth=none
- References: <1447092513-20690-1-git-send-email-brobecker at adacore dot com> <86y4e5wxy9 dot fsf at gmail dot com> <20151115172537 dot GA10374 at adacore dot com> <861tbqw8p5 dot fsf at gmail dot com> <20151118205840 dot GA3603 at adacore dot com>
Joel Brobecker <brobecker@adacore.com> writes:
> Here is how I understand things: The code is trying to figure out
> if our frame corresponds to a system call or not. For that, it searches
> the instruction at "get_frame_pc (this_frame) - 2" (or -4 for non-thumb).
> To me, the reason for the -2 or the -4, is that it implicitly makes
> the assumption that "get_frame_pc (this_frame)" is a *return address*.
Yeah, that is a good point...
> So, it has to check the instruction immediately before that return
> address. That assumption is not valid for the inner-most address.
>
> Imagine we have a function whose code has been compiled into:
>
> ...stuff...
> svc #imm
> insn #2 <<<-- breakpoint here
>
... and this is a good example too.
> ... and we're stopped at the breakpiont. In this case, get_frame_pc
> will return the address in "insn #2", and therefore see an "svc"
> instruction just before it, and conclude that we're stuck on a system
> call, which is not true.
>
>
> So, in my opinion, the patch I initially propose is still best.
> When you look at the patch with whitespace changes removed (attached),
> it is actually fairly tiny.
so, your initial patch is OK to me.
--
Yao (éå)