I think the issue is the behavior of ptrace. The data structures we need with ptrace are determined by the host regardless of the target. This is, of course, assuming a local target. I believe we can be sure we have that by the time the RegisterContext is created.
-Andy -----Original Message----- From: Greg Clayton [mailto:[email protected]] Sent: Monday, July 22, 2013 11:38 AM To: Kaylor, Andrew Cc: Michael Sartain; [email protected] Subject: Re: [lldb-dev] lldb test failures on 32bit So we have two code paths for i386? One for native 32 on 32 and one for cross 32 on 64? Can/should this be fixed? Greg On Jul 22, 2013, at 10:56 AM, "Kaylor, Andrew" <[email protected]> wrote: > Actually, RegisterContext_i386 doesn't get used in the case of a 32-bit > inferior on a 64-bit host. In that scenario we use RegisterContext_x86_64 > and do some mapping under the covers for 32-bit targets. > > -Andy > > -----Original Message----- > From: Greg Clayton [mailto:[email protected]] > Sent: Monday, July 22, 2013 10:19 AM > To: Kaylor, Andrew > Cc: Michael Sartain; [email protected] > Subject: Re: [lldb-dev] lldb test failures on 32bit > > I think the i386 problems are due to RegisterContext_i386 not doing its job: > > bool > RegisterContext_i386::ReadAllRegisterValues(DataBufferSP &data_sp) { > return false; > } > > > bool > RegisterContext_i386::WriteAllRegisterValues(const DataBufferSP &data) { > return false; > } > > > It also seems that WriteGPR() and WriteFPR() are not implemented??? > > > The ReadAllRegisterValues() call is used to backup the entire register state > prior to running expressions and WriteAllRegisterValues() is used to restore > them after running expressions. > > On Jul 19, 2013, at 5:25 PM, "Kaylor, Andrew" <[email protected]> wrote: > >> Hmmm... >> >> The program I was testing with passed a format argument to printf, and that >> works. If I just pass a string, I do see the failure you describe below. >> >> The logging output says it ran into an invalid RegisterContext while >> unwinding. I'll take a closer look on Monday. >> >> -Andy >> >> From: Michael Sartain [mailto:[email protected]] >> Sent: Friday, July 19, 2013 4:24 PM >> To: Kaylor, Andrew >> Cc: [email protected]; Malea, Daniel; Kopec, Matt; Thirumurthi, >> Ashok >> Subject: Re: lldb test failures on 32bit >> >> I applied both patches, and the 'expr (int)printf("blah\n")' statement now >> works, but "n" over the printf() statement in the code still throws me >> somewhere else entirely. I'm on the call printf() asm instruction down >> below, I type "ni", and I wind up at address 0x80486f0. >> >> Is this working for you? >> >> And thanks for looking at this Andrew. Very cool we can call functions now >> in 32-bit targets... >> -Mike >> >> (lldb) ni >> Process 18815 stopped >> * thread #1: tid = 0x497f, 0x08048855 blah`main(argc=1, argv=0xff985674) + >> 37 at blah.cpp:29, name = 'blah, stop reason = instruction step over >> frame #0: 0x08048855 blah`main(argc=1, argv=0xff985674) + 37 at >> blah.cpp:29 >> 26 >> 27 int main( int argc, char *argv[] ) >> 28 { >> -> 29 printf("hello world.\n"); >> 30 >> 31 Set *foo = new Set(); >> 32 >> (lldb) disassemble >> blah`main at blah.cpp:28: >> 0x8048830: push EBP >> 0x8048831: mov EBP, ESP >> 0x8048833: push ESI >> 0x8048834: sub ESP, 32820 >> 0x804883a: mov EAX, DWORD PTR [EBP + 12] >> 0x804883d: mov ECX, DWORD PTR [EBP + 8] >> 0x8048840: mov DWORD PTR [EBP - 8], 0 >> 0x8048847: mov DWORD PTR [EBP - 12], ECX >> 0x804884a: mov DWORD PTR [EBP - 16], EAX >> 0x804884d: mov EAX, ESP >> 0x804884f: mov DWORD PTR [EAX], 134515168 >> -> 0x8048855: call 0x80486f0 >> 0x804885a: mov ECX, ESP >> 0x804885c: mov DWORD PTR [ECX], 1 >> 0x8048862: mov DWORD PTR [EBP - 32804], EAX >> 0x8048868: call 0x8048700 >> 0x804886d: mov ECX, EAX >> 0x804886f: mov EDX, EAX >> 0x8048871: mov ESI, ESP >> 0x8048873: mov DWORD PTR [ESI], EAX >> 0x8048875: mov DWORD PTR [EBP - 32808], EDX >> 0x804887b: mov DWORD PTR [EBP - 32812], ECX >> 0x8048881: call 0x8048800 ; Set at blah.cpp:23 >> 0x8048886: jmp 0x804888b ; main + 91 at blah.cpp:31 >> 0x804888b: mov EAX, DWORD PTR [EBP - 32812] >> 0x8048891: mov DWORD PTR [EBP - 20], EAX >> 0x8048894: mov DWORD PTR [EBP - 32800], 0 >> 0x804889e: cmp DWORD PTR [EBP - 32800], 8192 >> 0x80488a8: jae 0x80488ef ; main + 191 at blah.cpp:38 >> 0x80488ae: call 0x8048710 >> 0x80488b3: mov ECX, DWORD PTR [EBP - 32800] >> 0x80488b9: mov DWORD PTR [EBP + 4*ECX - 32796], EAX >> 0x80488c0: mov EAX, DWORD PTR [EBP - 32800] >> 0x80488c6: add EAX, 1 >> 0x80488cb: mov DWORD PTR [EBP - 32800], EAX >> 0x80488d1: jmp 0x804889e ; main + 110 at blah.cpp:34 >> 0x80488d6: mov DWORD PTR [EBP - 24], EAX >> 0x80488d9: mov DWORD PTR [EBP - 28], EDX >> 0x80488dc: mov EAX, DWORD PTR [EBP - 32808] >> 0x80488e2: mov DWORD PTR [ESP], EAX >> 0x80488e5: call 0x80486d0 ; symbol stub for: >> _Unwind_Resume >> 0x80488ea: jmp 0x80488fb ; main + 203 at blah.cpp:31 >> 0x80488ef: mov EAX, DWORD PTR [EBP - 8] >> 0x80488f2: add ESP, 32820 >> 0x80488f8: pop ESI >> 0x80488f9: pop EBP >> 0x80488fa: ret >> 0x80488fb: mov EAX, DWORD PTR [EBP - 24] >> 0x80488fe: mov DWORD PTR [ESP], EAX >> 0x8048901: call 0x8048730 >> (lldb) ni >> Process 18815 stopped >> * thread #1: tid = 0x497f, 0x080486f0 blah, name = 'blah, stop reason = >> instruction step over >> frame #0: 0x080486f0 blah >> -> 0x80486f0: jmp DWORD PTR [134520844] >> 0x80486f6: push 24 >> 0x80486fb: jmp 0x80486b0 ; blah..plt + 0 >> 0x8048700: jmp DWORD PTR [134520848] >> >> On Fri, Jul 19, 2013 at 3:34 PM, Kaylor, Andrew <[email protected]> >> wrote: >> Hi Mike, >> >> I think I've tracked down the sources of both of these problems. >> >> The problem with not being able to call functions in the target seems to be >> a failure in the MCJIT relocation mechanism. Because LLDB is generating IR >> with absolute addresses for function calls, the JITed code contains >> relocations with absolute values rather than symbols. This is a problem I >> fixed a short time ago, but it seems to have come undone again (at least in >> this particular case). The attached 'reloc-fix-32.patch' (to be applied to >> the LLVM repository) should fix that. >> >> I need to do a bit of investigation to settle some questions about why this >> condition came back or was specific to the 32-bit case before I commit this, >> but I think this is correct. >> >> The problem where you lose source after stepping seems to be a matter of >> incorrect stack unwinding. There were two problems lurking here. >> >> First, the RegisterContext::ConvertBetweenRegisterKinds() function wasn't >> making any provision for a 32-bit inferior running on a 64-bit target. The >> way the x86-64 register context class is implemented it defines 64-bit >> registers and 32-bit registers in the same RegisterInfo structure, and there >> is some overlap in how these get mapped to DWARF/GDB/GCC register numbers. >> RegisterContext::ConvertBetweenRegisterKinds() was just iterating through >> the list and returning the first match it found, which was the 64-bit >> register. >> >> I added a special case to call >> RegisterContext::ConvertRegisterKindToRegisterNumber() when the target kind >> is eRegisterKindLLDB. This invokes the RegisterContext_x86_64 overload of >> that method which knows how to distinguish the 32-bit and 64-bit registers. >> I'm not convinced that this is the best way to solve this problem, but it >> works. >> >> The second issue was that the ABIMacOSX_i386 plug-in (which also gets used >> for 32-bit inferiors on Linux) was rejecting call frame addresses that >> weren't 8-byte aligned whereas, at least on Linux, 4-byte alignment is >> allowed. If 32-bit processes on MacOSX require 8-byte alignment then we'll >> need to do some additional checking, but for now I just modified it to only >> check for 4-byte alignment. >> >> Both of the stack unwinding issues should be fixed by the attached >> 'stack-fix-32.patch' file. >> >> Can you try out these patches and verify that they work for you? >> >> Thanks, >> Andy >> >> From: Michael Sartain [mailto:[email protected]] >> Sent: Tuesday, July 16, 2013 6:14 PM >> To: Malea, Daniel; Kaylor, Andrew; Kopec, Matt; Thirumurthi, Ashok >> Cc: Matthew Sorrels >> Subject: Fwd: lldb test failures on 32bit >> >> I think the below are the largest 32-bit blocking issues right now. >> >> Is this something any of you have any familiarity with and have time to look >> at? >> >> If not, let me know and I'll start investigating... >> >> Thanks much! >> -Mike >> >> ################################# >> ## Can't call functions in target >> ################################# >> mikesart@mikesart-rad:~/data/src/blah2/build$ lldb -x -- blah Current >> executable set to 'blah' (i386). >> (lldb) b main >> Breakpoint 1: where = blah`main + 29 at blah.cpp:29, address = >> 0x0804884d >> (lldb) r >> Process 6745 launched: '/home/mikesart/data/src/blah2/build/blah' >> (i386) Process 6745 stopped >> * thread #1: tid = 0x1a59, 0x0804884d blah`main(argc=1, argv=0xfffc8c54) + >> 29 at blah.cpp:29, name = 'blah, stop reason = breakpoint 1.1 >> frame #0: 0x0804884d blah`main(argc=1, argv=0xfffc8c54) + 29 at >> blah.cpp:29 >> 26 >> 27 int main( int argc, char *argv[] ) >> 28 { >> -> 29 printf("hello world.\n"); >> 30 >> 31 Set *foo = new Set(); >> 32 >> (lldb) expr (int)printf("hi there!\n"); >> error: Execution was interrupted, reason: invalid address (fault address: >> 0xeef60020). >> The process has been returned to the state before expression evaluation. >> (lldb) n >> Process 6745 exited with status = -1 (0xffffffff) >> >> ################################# >> ## Lose source with first next command >> ################################# >> mikesart@mikesart-rad:~/data/src/blah2/build$ lldb -x -- blah Current >> executable set to 'blah' (i386). >> (lldb) b main >> Breakpoint 1: where = blah`main + 29 at blah.cpp:29, address = >> 0x0804884d >> (lldb) r >> Process 7471 launched: '/home/mikesart/data/src/blah2/build/blah' >> (i386) Process 7471 stopped >> * thread #1: tid = 0x1d2f, 0x0804884d blah`main(argc=1, argv=0xffb36464) + >> 29 at blah.cpp:29, name = 'blah, stop reason = breakpoint 1.1 >> frame #0: 0x0804884d blah`main(argc=1, argv=0xffb36464) + 29 at >> blah.cpp:29 >> 26 >> 27 int main( int argc, char *argv[] ) >> 28 { >> -> 29 printf("hello world.\n"); >> 30 >> 31 Set *foo = new Set(); >> 32 >> (lldb) n >> Process 7471 stopped >> * thread #1: tid = 0x1d2f, 0x080486f0 blah, name = 'blah, stop reason = step >> over >> frame #0: 0x080486f0 blah >> -> 0x80486f0: jmpl *134520844 >> 0x80486f6: pushl $24 >> 0x80486fb: jmp 0x80486b0 ; blah..plt + 0 >> 0x8048700: jmpl *134520848 >> (lldb) >> >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
