Sounds like your dynamic loader is doing the wrong thing.
What does the output of:
(lldb) image dump sections
What does this show? My guess if you might have overlapping sections. You can
also get info on an address by doing:
(lldb) image lookup --verbose --address 0x00415086
This will show you which section it thinks it resolved to and also what debug
symbols.
On MacOSX we had issues where we had images in memory where one of the sections
wasn't really getting loaded, but we said it was (dynamic loader error). So we
had a file a.dylib:
a.dylib whose __TEXT section had a load addr range [0x0000 - 0x1000)
a.dylib whose __DATA section had a load addr range [0x1000 - 0x2000)
a.dylib whose __LINKEDIT section had a load addr range [0x2000 - 0x3000)
But __LINKEDIT wasn't actually being mapped by the kernel, and we then had:
b.dylib whose __TEXT section had a load addr range [0x2000 - 0x3000)
b.dylib whose __DATA section had a load addr range [0x3000 - 0x4000)
b.dylib whose __LINKEDIT section had a load addr range [0x4000 - 0x5000)
Note that a.dylib.__LINKEDIT overlaps with b.dylib. __TEXT.
We fixed the dynamic loader to not slide _all_ sections, just the ones that
were loaded, so the map actually was:
a.dylib whose __TEXT section had a load addr range [0x0000 - 0x1000)
a.dylib whose __DATA section had a load addr range [0x1000 - 0x2000)
a.dylib whose __LINKEDIT not loaded in process
But __LINKEDIT wasn't actually being mapped by the kernel, and we then had:
b.dylib whose __TEXT section had a load addr range [0x2000 - 0x3000)
b.dylib whose __DATA section had a load addr range [0x3000 - 0x4000)
b.dylib whose __LINKEDIT not loaded in process
Then our address lookups all worked. Just a guess as to what might be happening.
Greg
> On Jan 21, 2015, at 5:09 PM, Zachary Turner <ztur...@google.com> wrote:
>
> So I think my problem with stack unwinding and thread step-over (or my
> immediate problem anyway) is somewhat unrelated to the long discussion we had
> earlier, and is much simpler.
>
> (lldb) Process 9140 stopped
> * thread #1: tid = 0x2ef8, 0x00415086 expr_test.exe`main + 70 at
> expr_test.cpp:29, stop reason = breakpoint 1.1
> frame #0: 0x00415086 expr_test.exe`main + 70 at expr_test.cpp:29
>
> The address given here is 0x415086. And indeed, if I disassemble this
> address, I see actual code.
>
> invalid command 'frame #0:'
> (lldb) dis -n main -F intel
> ...
> -> 0x415086 <main+70>: mov dword ptr [esp], ecx
> 0x415089 <main+73>: mov dword ptr [ebp - 0xc], eax
> 0x41508c <main+76>: call 0x4150d7
>
> (lldb) dis -s 0x415086 -F intel
> -> 0x415086 <main+70>: mov dword ptr [esp], ecx
> 0x415089 <main+73>: mov dword ptr [ebp - 0xc], eax
> 0x41508c <main+76>: call 0x4150d7
> 0x415091 <main+81>: lea ecx, [0x41006e]
> 0x415097 <main+87>: mov dword ptr [esp], ecx
> 0x41509a <main+90>: mov dword ptr [ebp - 0x10], eax
> 0x41509d <main+93>: call 0x4150d7
>
> But when I try to set a breakpoint at that address, bad stuff happens:
> (lldb) break set -a 0x415086
> warning: failed to set breakpoint site at 0x415086 for breakpoint 2.1: Unable
> to read memory at breakpoint address.
> Breakpoint 2: where = expr_test.exe`main + 70 at expr_test.cpp:29, address =
> 0x00415086
>
> I modified the source of my program to print out the image base and the
> address of main at startup by adding these two lines:
>
> printf("main = 0x%p\n", main);
> printf("_ImageBase = 0x%p", &__ImageBase);
>
> And this prints out the following:
> main = 0x00AE5040
> _ImageBase = 0x00AD0000
>
> Note that the address of main printed by my program is quite far off from the
> address reported by LLDB.
>
> If I run llvm-readobj on my COFF file, I see this:
>
> BaseOfCode: 0x15000
> ImageBase: 0x400000
>
> Adding these two together, I get 0x415000, which is only 0x86 bytes away from
> what LLDB Is reporting as the instruction I'm broken at.
>
> So, in short: It's not taking into account the load address of the executable
> module.
>
> I checked my process plugin, and when the debugger connects to the process,
> it does get the load address which is 0x00AD0000 and it create a ModuleSP for
> it, it calls SetLoadAddress, and then it calls ModulesDidLoad.
>
> But in the end, some part of LLDB still isn't happy.
>
> How this all relates to thread step-over is that LLDB is trying to set an
> address breakpoint on a 0x415xxx address, which is only a RVA that needs to
> be added to the load address.
>
> I must be missing a step somewhere, but I'm not quite sure what.
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
