[Lldb-commits] [lldb] r282683 - Add a unit test for an x86_64 assembly inspection of
Jason Molenda via lldb-commits
lldb-commits at lists.llvm.org
Fri Sep 30 13:11:54 PDT 2016
Thanks for the help! It took me most of yesterday to get gcc-4.9 built (it's been more than a decade since I've built gcc) - I think I've got it set up now, so I'll figure this out today. I'm in the middle of looking into a bug in the 32-bit assembly assembly instruction unwind plan creation that I turned up while writing a unit test, but I'll look at this as soon as I'm done with that.
J
> On Sep 30, 2016, at 5:27 AM, Pavel Labath <labath at google.com> wrote:
>
> I made a quick investigation today. The problem is indeed specific to gcc-4.9. The main differences I could see is that gcc-4.9 generates a different prologue for the function, and uses pushl for argument passing. This confuses the emulator/augmenter and the unwind information at some points ends up being incorrect. Since the problem starts to occur after the first pushl instruction, i am guessing the problem is with those. I'll try to investigate more next week.
>
> For reference, the function with 4.9 looks like this:
>
> a.out`main:
>
> 0x80484eb <+0>: leal 0x4(%esp), %ecx
>
> 0x80484ef <+4>: andl $-0x10, %esp
>
> 0x80484f2 <+7>: pushl -0x4(%ecx)
>
> 0x80484f5 <+10>: pushl %ebp
>
> 0x80484f6 <+11>: movl %esp, %ebp
>
> 0x80484f8 <+13>: pushl %edi
>
> 0x80484f9 <+14>: pushl %esi
>
> 0x80484fa <+15>: pushl %ebx
>
> 0x80484fb <+16>: pushl %ecx
>
> 0x80484fc <+17>: subl $0x28, %esp
>
> 0x80484ff <+20>: subl $0xc, %esp
>
> 0x8048502 <+23>: pushl $0x18
>
> 0x8048504 <+25>: calll 0x80483d0 ; symbol stub for: operator new[](unsigned int)
>
> 0x8048509 <+30>: addl $0x10, %esp
>
> 0x804850c <+33>: movl %eax, %edi
>
> 0x804850e <+35>: movl %edi, %eax
>
> 0x8048510 <+37>: movl $0x1, %esi
>
> 0x8048515 <+42>: movl %eax, %ebx
>
> 0x8048517 <+44>: jmp 0x804852b ; <+64> at main.cpp:26
>
> 0x8048519 <+46>: subl $0xc, %esp
>
> 0x804851c <+49>: pushl %ebx
>
> 0x804851d <+50>: calll 0x80485cc ; foo::foo at main.cpp:16
>
> 0x8048522 <+55>: addl $0x10, %esp
>
> 0x8048525 <+58>: addl $0xc, %ebx
>
> 0x8048528 <+61>: subl $0x1, %esi
>
> 0x804852b <+64>: cmpl $-0x1, %esi
>
> 0x804852e <+67>: jne 0x8048519 ; <+46> at main.cpp:26
>
> 0x8048530 <+69>: movl %edi, -0x1c(%ebp)
>
> 0x8048533 <+72>: movl -0x1c(%ebp), %eax
>
> 0x8048536 <+75>: movl $0x1, (%eax)
>
> 0x804853c <+81>: movl -0x1c(%ebp), %eax
>
> 0x804853f <+84>: movl $0x9, 0x4(%eax)
>
> 0x8048546 <+91>: movl -0x1c(%ebp), %eax
>
> 0x8048549 <+94>: addl $0xc, %eax
>
> 0x804854c <+97>: movl $0x8, (%eax)
>
> 0x8048552 <+103>: movl -0x1c(%ebp), %eax
>
> 0x8048555 <+106>: addl $0xc, %eax
>
> 0x8048558 <+109>: movl $0x5, 0x4(%eax)
>
> 0x804855f <+116>: movl -0x1c(%ebp), %eax
>
> 0x8048562 <+119>: addl $0xc, %eax
>
> 0x8048565 <+122>: movl $0x7, 0x4(%eax)
>
> 0x804856c <+129>: movl -0x1c(%ebp), %eax
>
> 0x804856f <+132>: leal 0xc(%eax), %edx
>
> 0x8048572 <+135>: movl 0x80486a4, %eax
>
> 0x8048577 <+140>: movl %eax, 0x8(%edx)
>
> 0x804857a <+143>: leal -0x34(%ebp), %ebx
>
> 0x804857d <+146>: movl 0x80486a8, %eax
>
> 0x8048582 <+151>: pushl %eax
>
> 0x8048583 <+152>: pushl $0x2
>
> 0x8048585 <+154>: pushl $0x1
>
> 0x8048587 <+156>: pushl %ebx
>
> -> 0x8048588 <+157>: calll 0x80485f0 ; foo::foo at main.cpp:17
>
> 0x804858d <+162>: addl $0x10, %esp
>
> 0x8048590 <+165>: leal 0xc(%ebx), %edx
>
> 0x8048593 <+168>: movl 0x80486ac, %eax
>
> 0x8048598 <+173>: pushl %eax
>
> 0x8048599 <+174>: pushl $0x5
>
> 0x804859b <+176>: pushl $0x4
>
> 0x804859d <+178>: pushl %edx
>
> 0x804859e <+179>: calll 0x80485f0 ; foo::foo at main.cpp:17
>
> 0x80485a3 <+184>: addl $0x10, %esp
>
> 0x80485a6 <+187>: cmpl $0x0, -0x1c(%ebp)
>
> 0x80485aa <+191>: je 0x80485ba ; <+207> at main.cpp:42
>
> 0x80485ac <+193>: subl $0xc, %esp
>
> 0x80485af <+196>: pushl -0x1c(%ebp)
>
> 0x80485b2 <+199>: calll 0x80483e0 ; symbol stub for: operator delete[](void*)
>
> 0x80485b7 <+204>: addl $0x10, %esp
>
> 0x80485ba <+207>: movl $0x0, %eax
>
> 0x80485bf <+212>: leal -0x10(%ebp), %esp
>
> 0x80485c2 <+215>: popl %ecx
>
> 0x80485c3 <+216>: popl %ebx
>
> 0x80485c4 <+217>: popl %esi
>
> 0x80485c5 <+218>: popl %edi
>
> 0x80485c6 <+219>: popl %ebp
>
> 0x80485c7 <+220>: leal -0x4(%ecx), %esp
>
> 0x80485ca <+223>: retl
>
>
>
>
>
> whereas the same function compiled with gcc-4.8 is this:
>
> 0x804850d <+0>: pushl %ebp
>
> 0x804850e <+1>: movl %esp, %ebp
>
> 0x8048510 <+3>: pushl %edi
>
> 0x8048511 <+4>: pushl %esi
>
> 0x8048512 <+5>: pushl %ebx
>
> 0x8048513 <+6>: andl $-0x10, %esp
>
> 0x8048516 <+9>: subl $0x30, %esp
>
> 0x8048519 <+12>: movl $0x18, (%esp)
>
> 0x8048520 <+19>: calll 0x80483f0 ; symbol stub for: operator new[](unsigned int)
>
> 0x8048525 <+24>: movl %eax, %edi
>
> 0x8048527 <+26>: movl %edi, %eax
>
> 0x8048529 <+28>: movl $0x1, %esi
>
> 0x804852e <+33>: movl %eax, %ebx
>
> 0x8048530 <+35>: jmp 0x8048540 ; <+51> at main.cpp:26
>
> 0x8048532 <+37>: movl %ebx, (%esp)
>
> 0x8048535 <+40>: calll 0x8048600 ; foo::foo at main.cpp:16
>
> 0x804853a <+45>: addl $0xc, %ebx
>
> 0x804853d <+48>: subl $0x1, %esi
>
> 0x8048540 <+51>: cmpl $-0x1, %esi
>
> 0x8048543 <+54>: jne 0x8048532 ; <+37> at main.cpp:26
>
> 0x8048545 <+56>: movl %edi, 0x14(%esp)
>
> 0x8048549 <+60>: movl 0x14(%esp), %eax
>
> 0x804854d <+64>: movl $0x1, (%eax)
>
> 0x8048553 <+70>: movl 0x14(%esp), %eax
>
> 0x8048557 <+74>: movl $0x9, 0x4(%eax)
>
> 0x804855e <+81>: movl 0x14(%esp), %eax
>
> 0x8048562 <+85>: addl $0xc, %eax
>
> 0x8048565 <+88>: movl $0x8, (%eax)
>
> 0x804856b <+94>: movl 0x14(%esp), %eax
>
> 0x804856f <+98>: addl $0xc, %eax
>
> 0x8048572 <+101>: movl $0x5, 0x4(%eax)
>
> 0x8048579 <+108>: movl 0x14(%esp), %eax
>
> 0x804857d <+112>: addl $0xc, %eax
>
> 0x8048580 <+115>: movl $0x7, 0x4(%eax)
>
> 0x8048587 <+122>: movl 0x14(%esp), %eax
>
> 0x804858b <+126>: leal 0xc(%eax), %edx
>
> 0x804858e <+129>: movl 0x80486e4, %eax
>
> 0x8048593 <+134>: movl %eax, 0x8(%edx)
>
> 0x8048596 <+137>: leal 0x18(%esp), %ebx
>
> 0x804859a <+141>: movl 0x80486e8, %eax
>
> 0x804859f <+146>: movl %eax, 0xc(%esp)
>
> 0x80485a3 <+150>: movl $0x2, 0x8(%esp)
>
> 0x80485ab <+158>: movl $0x1, 0x4(%esp)
>
> 0x80485b3 <+166>: movl %ebx, (%esp)
>
> 0x80485b6 <+169>: calll 0x8048624 ; foo::foo at main.cpp:17
>
> 0x80485bb <+174>: leal 0xc(%ebx), %edx
>
> 0x80485be <+177>: movl 0x80486ec, %eax
>
> 0x80485c3 <+182>: movl %eax, 0xc(%esp)
>
> 0x80485c7 <+186>: movl $0x5, 0x8(%esp)
>
> 0x80485cf <+194>: movl $0x4, 0x4(%esp)
>
> 0x80485d7 <+202>: movl %edx, (%esp)
>
> 0x80485da <+205>: calll 0x8048624 ; foo::foo at main.cpp:17
>
> -> 0x80485df <+210>: cmpl $0x0, 0x14(%esp)
>
> 0x80485e4 <+215>: je 0x80485f2 ; <+229> at main.cpp:42
>
> 0x80485e6 <+217>: movl 0x14(%esp), %eax
>
> 0x80485ea <+221>: movl %eax, (%esp)
>
> 0x80485ed <+224>: calll 0x8048400 ; symbol stub for: operator delete[](void*)
>
> 0x80485f2 <+229>: movl $0x0, %eax
>
> 0x80485f7 <+234>: leal -0xc(%ebp), %esp
>
> 0x80485fa <+237>: popl %ebx
>
> 0x80485fb <+238>: popl %esi
>
> 0x80485fc <+239>: popl %edi
>
> 0x80485fd <+240>: popl %ebp
>
>
> 0x80485fe <+241>: retl
>
>
> On 29 September 2016 at 14:22, Jason Molenda <jmolenda at apple.com> wrote:
> Interesting, I can't get the failure to repo with i386 + gcc-4.8 on an ubuntu 14.04.5 system. Downloading & building gcc-4.9.4 right now.
>
>
>
> $ ./dotest.py -C gcc-4.8 -A i386 --executable ~/build/bin/lldb testcases/python_api/sbdata
> LLDB library dir: /home/jmolenda/build/bin
> LLDB import library dir: /home/jmolenda/build/bin
> lldb version 4.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk revision 282753 clang revision 282567 llvm revision 282567)
> The 'lldb-mi' executable cannot be located. The lldb-mi tests can not be run as a result.
>
> Session logs for test failures/errors/unexpected successes will go into directory '2016-09-29-15_09_05'
> Command invoked: ./dotest.py -C gcc-4.8 -A i386 --executable /home/jmolenda/build/bin/lldb testcases/python_api/sbdata
> compilers=['gcc-4.8']
>
> Configuration: arch=i386 compiler=gcc-4.8
> ----------------------------------------------------------------------
> Collected 2 tests
>
> ----------------------------------------------------------------------
> Ran 2 tests in 1.540s
>
> RESULT: PASSED (2 passes, 0 failures, 0 errors, 0 skipped, 0 expected failures, 0 unexpected successes)
>
>
> J
>
> > On Sep 29, 2016, at 12:29 PM, Jason Molenda <jmolenda at apple.com> wrote:
> >
> > Yep, will do. I saw that build bot result last night and ran the testsuite on my local ubuntu box and didn't repo the failure so I thought maybe it was an already-failing test case that the bot was just telling me about. But I think I was running the test x86_64 - I'll figure out how to run it i386 and look into it.
> >
> >> On Sep 29, 2016, at 5:56 AM, Pavel Labath <labath at google.com> wrote:
> >>
> >> Note that the test fails when using gcc as a compiler (specifically gcc-4.9 in this case, but hopefully the exact version does not matter here).
> >>
> >> Jason, will you be able to check this out today?
> >>
> >> On 29 September 2016 at 05:45, Dimitar Vlahovski via lldb-commits <lldb-commits at lists.llvm.org> wrote:
> >> This is the first build that failed right after your CL: http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/20083
> >>
> >> On Thu, Sep 29, 2016 at 1:35 PM, Dimitar Vlahovski <dvlahovski at google.com> wrote:
> >> Hi,
> >>
> >> Is the work that you are currently doing the reason why the lldb build on i386 is failing?
> >> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake
> >> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/20099
> >>
> >> Dimitar
> >>
> >>
> >> On Thu, Sep 29, 2016 at 5:30 AM, Jason Molenda via lldb-commits <lldb-commits at lists.llvm.org> wrote:
> >> Good suggestions, thanks. I'll fix those when I commit the 32-bit version of the same test.
> >>
> >> J
> >>
> >>> On Sep 28, 2016, at 9:28 PM, Zachary Turner <zturner at google.com> wrote:
> >>>
> >>>
> >>>
> >>> On Wed, Sep 28, 2016 at 9:10 PM Jason Molenda via lldb-commits <lldb-commits at lists.llvm.org> wrote:
> >>>
> >>> + EXPECT_TRUE(regloc.GetOffset() == -8);
> >>> This should be
> >>>
> >>> EXPECT_EQ(-8, regloc.GetOffset());
> >>>
> >>> That way if it fails, you'll get a handy error message that says:
> >>>
> >>> Expected: -8
> >>> Actual: -7
> >>>
> >>> If you use EXPECT_TRUE, it's not going to tell you the actual value. The same goes for many other places in the file. Note that you're supposed to put the expected value *first*. The test is the same either way obviously, but it affects the printing of the above message.
> >>>
> >>> +
> >>> + // these could be set to IsSame and be valid -- meaning that the
> >>> + // register value is the same as the caller's -- but I'd rather
> >>> + // they not be mentioned at all.
> >>> + EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbp, regloc) == false);
> >>> + EXPECT_TRUE(row_sp->GetRegisterInfo(k_r15, regloc) == false);
> >>> + EXPECT_TRUE(row_sp->GetRegisterInfo(k_r14, regloc) == false);
> >>> + EXPECT_TRUE(row_sp->GetRegisterInfo(k_r13, regloc) == false);
> >>> + EXPECT_TRUE(row_sp->GetRegisterInfo(k_r12, regloc) == false);
> >>> + EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbx, regloc) == false);
> >>> If you're using EXPECT_TRUE and EXPECT_FALSE, I think it's more intuitive to not use the comparison operator. The above is just
> >>>
> >>> EXPECT_FALSE(row_sp->GetRegisterInfo(k_rbx, regloc));
> >>
> >> _______________________________________________
> >> lldb-commits mailing list
> >> lldb-commits at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> >>
> >>
> >>
> >> _______________________________________________
> >> lldb-commits mailing list
> >> lldb-commits at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> >>
> >>
> >
>
>
More information about the lldb-commits
mailing list