the "payload_length" argument for the "payload" packet data. This meant we
could end up sending random extra data with a packet depending on how the
packet was constructed.
Fixed GDBRemoteRegisterContext to properly save and restore all registers.
Previous fixes had been added to work around the "payload_length" issues fixed
above and aren't needed anymore.
Fix logging in GDBRemoteCommunication to make sure we log the correct packet
data being sent by using the packet length when dumping the packet contents.
Added register definitions for 'arm-lldb' in the "disasm-gdb-remote.pl" script
so if you have a register dump from the GDB remote that doesn't include the
qRegisterInfo packets, you can manually tell the script which registers are
which.
llvm-svn: 131715
packet output from "log enable gdb-remote packets". This should help people
track down and see what is going wrong more easily when you have log output
that includes GDB remote packets.
llvm-svn: 131713
breaks it for you (or if the LanguageRuntime plugins break the build on your
machine), please let me know and I'll revert.
Also, link to CoreServices and Carbon on Mac. Yep, LLDB needs these ancient
frameworks.
llvm-svn: 131707
Mac OS X Process plugin from the build.
I'm surprised no one caught this earlier. Am I the only one who builds with
the makefiles on Mac?
llvm-svn: 131704
Removed ifdeffed out functions and added the implementation of
WriteRegister for x86_64 architecture.
Signed-off-by: Johnny Chen <johnny.chen@apple.com>
llvm-svn: 131696
Host.cpp was missing Error.h and the implementation of
LaunchProcess. Once againg I have added a "fake" implementation
waiting for a real one.
Fixed the call GetAddressRange to reflect the new interface in
DynamicLoaderLinuxDYLD.cpp.
Added string.h to ARM_DWARF_Registers.cpp that is needed for ::memset.
Signed-off-by: Johnny Chen <johnny.chen@apple.com>
llvm-svn: 131695
text section.
Assume the following bit of annotated assembly:
.section .data.rel.ro,"aw",%progbits
.align 2
.LAlpha:
.long startval(GOTOFF)
.text
.align 2
.type main,%function
.align 4
main: ;;; assume "main" starts at offset 0x20
0x0 push {r11, lr}
0x4 movw r0, :lower16:(.LAlpha-(.LBeta+8))
;;; ==> (.AddrOf(.LAlpha) - ((.AddrOf(.LBeta) - .AddrOf(".")) + 8)
;;; ==> (??? - ((16-4) + 8) = -20
0x8 movt r0, :upper16:(.LAlpha-(.LBeta+8))
;;; ==> (.AddrOf(.LAlpha) - ((.AddrOf(.LBeta) - .AddrOf(".")) + 8)
;;; ==> (??? - ((16-8) + 8) = -16
0xc ... blah
.LBeta:
0x10 add r0, pc, r0
0x14 ... blah
.LGamma:
0x18 add r1, pc, r1
Above snippet results in the following relocs in the .o file for the
first pair of movw/movt instructions
00000024 R_ARM_MOVW_PREL_NC .LAlpha
00000028 R_ARM_MOVT_PREL .LAlpha
And the encoded instructions in the .o file for main: must be
00000020 <main>:
20: e92d4800 push {fp, lr}
24: e30f0fec movw r0, #65516 ; 0xffec i.e. -20
28: e34f0ff0 movt r0, #65520 ; 0xfff0 i.e. -16
However, llc (prior to this commit) generates the following sequence
00000020 <main>:
20: e92d4800 push {fp, lr}
24: e30f0fec movw r0, #65516 ; 0xffec - i.e. -20
28: e34f0fff movt r0, #65535 ; 0xffff - i.e. -1
What has to happen in the ArmAsmBackend is that if the relocation is PC
relative, the 16 bits encoded as part of movw and movt must be both addends,
not addresses. It makes sense to encode addresses by right shifting the value
by 16, but the result is incorrect for PIC.
i.e., the right shift by 16 for movt is ONLY valid for the NON-PCRel case.
This change agrees with what GNU as does, and makes the PIC code run.
MC/ARM/elf-movt.s covers this case.
llvm-svn: 131674
Cameron Zwarich