[lldb-dev] resolved load addresses vs. unresolved offset addresses

[Greg Clayton]

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 <zturner at 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 at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev