To add to what Greg described you may also want to look at section 6.4.4 of the
DWARF 5 specification that discusses these issues. In particular note the
non-normative description in the fourth paragraph.
> 6.4.4 Call Frame Calling Address
>
> *When virtually unwinding frames, consumers
You are correct. For the first frame you don't adjust the PC when looking up
the unwind row. For the second frame on up you can decrement the PC value by 1
before when doing the row lookup and that is usually enough to get you to the
correct unwind row. The issue is that the return address
A compiler may promote part of a variable to a scratch pad memory address space.
Thanks,
-Tony Tye
-Original Message-
From: Michael Eager
On 7/30/20 5:17 PM, Tye, Tony via Dwarf-Discuss wrote:
> For optimized code involving multiple address spaces it is possible to
> run into cases
Hello Michael,
Sorry for the late reply. I found the email in the spam folder today.
> >>> We'd also want an unbounded piece operator to describe partially
> registerized
> >>> unbounded arrays, but I have not worked that out in detail, yet, and
> >>> we're a
> bit
> >>> farther away from an
Hi -
> Can you explain this more?
>
> DWARF handles the situation where part of a variable is in memory and part
> in a register or in multiple registers. When would you have a variable
> which was in multiple address spaces?
Remember the "how can a debugger WRITE safely to variables"
Hello together!
I am running into a problem while performing a stack trace of x86 code. The
assembly code I am running has been generated by mingw from C++ code and
looks like this:
6c9c1210 <__ZN7my_class9my_methodEs>:
6c9c1210: sub$0x1c,%esp
6c9c1213: mov0x20(%esp),%edx
6c9c1217: mov
