systems (ios, tvos, watchos). It's a simple format to use now that
I have i386/x86_64 supported already.
The unwind instructions are only valid at call sites -- that is,
when lldb is unwinding a frame in the middle of the stack. It
cannot be used for the currently executing frame; it has no information
about prologues/epilogues/etc.
<rdar://problem/12062336>
llvm-svn: 270658
"gcc" register numbers are now correctly referred to as "ehframe"
register numbers. In almost all cases, ehframe and dwarf register
numbers are identical (the one exception is i386 darwin where ehframe
regnums were incorrect).
The old "gdb" register numbers, which I incorrectly thought were
stabs register numbers, are now referred to as "Process Plugin"
register numbers. This is the register numbering scheme that the
remote process controller stub (lldb-server, gdbserver, core file
support, kdp server, remote jtag devices, etc) uses to refer to the
registers. The process plugin register numbers may not be contiguous
- there are remote jtag devices that have gaps in their register
numbering schemes.
I removed all of the enums for "gdb" register numbers that we had
in lldb - these were meaningless - and I put LLDB_INVALID_REGNUM
in all of the register tables for the Process Plugin regnum slot.
This change is almost entirely mechnical; the one actual change in
here is to ProcessGDBRemote.cpp's ParseRegisters() which parses the
qXfer:features:read:target.xml response. As it parses register
definitions from the xml, it will assign sequential numbers as the
eRegisterKindLLDB numbers (the lldb register numberings must be
sequential, without any gaps) and if the xml file specifies register
numbers, those will be used as the eRegisterKindProcessPlugin
register numbers (and those may have gaps). A J-Link jtag device's
target.xml does contain a gap in register numbers, and it only
specifies the register numbers for the registers after that gap.
The device supports many different ARM boards and probably selects
different part of its register file as appropriate.
http://reviews.llvm.org/D12791
<rdar://problem/22623262>
llvm-svn: 247741
for eh_frame and stabs register numberings. This is not
complete but it's a step in the right direction. It's almost
entirely mechanical.
lldb informally uses "gcc register numbering" to mean eh_frame.
Why? Probably because there's a notorious bug with gcc on i386
darwin where the register numbers in eh_frame were incorrect.
In all other cases, eh_frame register numbering is identical to
dwarf.
lldb informally uses "gdb register numbering" to mean stabs.
There are no official definitions of stabs register numbers
for different architectures, so the implementations of gdb
and gcc are the de facto reference source.
There were some incorrect uses of these register number types
in lldb already. I fixed the ones that I saw as I made
this change.
This commit changes all references to "gcc" and "gdb" register
numbers in lldb to "eh_frame" and "stabs" to make it clear
what is actually being represented.
lldb cannot parse the stabs debug format, and given that no
one is using stabs any more, it is unlikely that it ever will.
A more comprehensive cleanup would remove the stabs register
numbers altogether - it's unnecessary cruft / complication to
all of our register structures.
In ProcessGDBRemote, when we get register definitions from
the gdb-remote stub, we expect to see "gcc:" (qRegisterInfo)
or "gcc_regnum" (qXfer:features:read: packet to get xml payload).
This patch changes ProcessGDBRemote to also accept "ehframe:"
and "ehframe_regnum" from these remotes.
I did not change GDBRemoteCommunicationServerLLGS or debugserver
to send these new packets. I don't know what kind of interoperability
constraints we might be working under. At some point in the future
we should transition to using the more descriptive names.
Throughout lldb we're still using enum names like "gcc_r0" and "gdb_r0",
for eh_frame and stabs register numberings. These should be cleaned
up eventually too.
The sources link cleanly on macosx native with xcode build. I
don't think we'll see problems on other platforms but please let
me know if I broke anyone.
llvm-svn: 245141
Removed some unused variables, added some consts, changed some casts
to const_cast. I don't think any of these changes are very
controversial.
Differential Revision: http://reviews.llvm.org/D9674
llvm-svn: 237218
compact unwind encodings for x86_64 / i386 omit-frame-pointer
code. It was possible for lldb to get the location of saved
registers incorrect for some of these functions.
<rdar://problem/20753264>
llvm-svn: 236478
There were a couple of real bugs here regarding error checking and
signed/unsigned comparisons, but mostly these were just noise.
There was one class of bugs fixed here which is particularly
annoying, dealing with MSVC's non-standard behavior regarding
the underlying type of enums. See the comment in
lldb-enumerations.h for details. In short, from now on please use
FLAGS_ENUM and FLAGS_ANONYMOUS_ENUM when defining enums which
contain values larger than can fit into a signed integer.
llvm-svn: 233943
Summary:
This change refactors UnwindPlan::Row to be able to store the fact that the CFA is value is set
by evaluating a dwarf expression (DW_CFA_def_cfa_expression). This is achieved by creating a new
class CFAValue and moving all CFA setting/getting code there. Note that code using the new
CFAValue::isDWARFExpression is not yet present and will be added in a follow-up patch. Therefore,
this patch should not change the functionality in any way.
Test Plan: Ran tests on Mac and Linux. No regressions detected.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7755
llvm-svn: 230210
i386/x86_64 functions. The stack size was being multiplied by the
pointer size incorrectly. The register permutation placeholders
(UNWIND_X86_REG_NONE) were decrementing the stack offset of the
saved registers when it should not have been.
<rdar://problem/19570035>
llvm-svn: 226889
This completes the compact unwind support for x86 targets.
I'm still skipping the UNWIND_X86_64_MODE_STACK_IND encodings for
x86_64 right now because clang was emitting bad data for this form
until it was fixed in r217020 circa Sep 2014.
arm64 parsing still needs to be added.
llvm-svn: 224698
Most of the changes are to the FuncUnwinders class -- as we've added
more types of unwind information, the way this class was written was
making it a mess to maintain. Instead of trying to keep one
"non-call site" unwind plan and one "call site" unwind plan, track
all the different types of unwind plans we can possibly retrieve for
each function and have the call-site/non-call-site accessor methods
retrieve those.
Add a real "fast unwind plan" for x86_64 / i386 -- when doing an
unwind through a function, this only has to read the first 4 bytes
to tell if the function has a standard prologue sequence. If so,
we can use the architecture default unwind plan to backtrace
through this function. If we try to retrieve the save location for
other registers later on, a real unwind plan will be used. This
one is just for doing fast backtraces.
Change the compact unwind plan importer to fill in the valid address
range it is valid for.
Compact unwind, in theory, may have multiple entries for a single
function. The FuncUnwinders rewrite includes the start of supporting
this correctly. In practice compact unwind encodings are used for
the entire range of the function today -- in fact, sometimes the same
encoding is used for multiple functions that have the same unwind
rules. But I want to handle a single function that has multiple
different compact unwind UnwindPlans eventually.
llvm-svn: 224689
When lldb has a binary with protected section contents,
don't use the on-disk representation of that compact
uwnind -- read it only out of live memory where it has
been decrypted.
llvm-svn: 224670
The compact unwind importer is getting the wrong unwind info for one
case that I found. I haven't been able to fix the problem tonight
and I don't want to leave TOT behaving incorrectly, so just ignore
compact unwind until I can get to the bottom of this.
llvm-svn: 224321
section for x86_64 and i386 targets on Darwin systems. Currently only the
compact unwind encoding for normal frame-using functions is supported but it
will be easy handle frameless functions when I have a bit more free time to
test it. The LSDA and personality routines for functions are also retrieved
correctly for functions from the compact unwind section.
This new code is very fresh -- it passes the lldb testsuite and I've done
by-hand inspection of many functions and am getting correct behavior for all
of them. There may need to be some bug fixing over the next couple weeks as
I exercise and test it further. But I think it's fine right now so I'm
committing it.
<rdar://problem/13220837>
llvm-svn: 223625
Jason Molenda