[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tcf-dev] Stack trace evaluation in the UI
|
Hi Eugene,
I'm still a little confused.
So what you'd really want is computing the "previous instruction". But doing just PC-1 won't give you that on architectures with variable instruction length. I know that on Intel at least, it is very nontrivial to compute the "previous instruction address".
I understand that doing PC-1 might give you the expected line number from the ELF/Dwarf debug info ... but what about the stacktracing code that wants to accurately compute the assembly return address ? And what about debugging scenarios where no debug info is available ?
If the stack crawl knows that the UI consistently always does PC-1 already that might work, though it feels strange ... were you planning to document that behavior in the TCF API Docs ?
Since it looks like any implementer of a stack crawl would need to be aware of that peculiar behavior, right ?
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Christophe Augier
Sent: Tuesday, May 14, 2013 3:08 PM
To: tcf-dev@xxxxxxxxxxx
Subject: Re: [tcf-dev] Stack trace evaluation in the UI
On 5/14/2013 12:57 AM, Eugene Tarassov wrote:
> The rationale behind it goes like this:
> Since it is not a top frame, PC is return address - it points to an instruction after call instruction, and PC-1 is address of last byte of the call instruction. So, to lookup a caller, PC-1 is used. In other words, we want to show a function that owns the call instruction. Same is done with line number info. Actually, it is done mostly because of the line number info - most users want see line that contain the call, not the line which contains return address.
Makes sense. Thanks Eugene for explaining!
- Christophe
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev
