[Lldb-commits] [PATCH] D55356: Add a method to get the "base" file address of an object file

Zachary Turner via lldb-commits lldb-commits at lists.llvm.org
Tue Dec 11 14:54:34 PST 2018

On Tue, Dec 11, 2018 at 11:57 AM Pavel Labath <pavel at labath.sk> wrote:

> The part I know nothing about is whether something similar could be done
> for PE/COFF files (and I'll need something like that there too). Adrian,
> Zachary, what is the relation ship between "image base" of an object
> file and its sections? Is there any way we could arrange so that the
> base address of a module always belongs to one of its sections?
Historically, an image base of N was used as a way to tell the loader "map
the file in so that byte 0 of the file is virtual address N in the
process's address space".  as in *((char *)N) would be the first byte of
the file in a running process.  Then, everything else in the file is
written as an offset from N.  This includes section addresses.  So for
example, if we use dumpbin on a simple executable we can see something like

Dump of file bin\count.exe

PE signature found


       140000000 image base (0000000140000000 to 0000000140011FFF)
   .text name
    1000 virtual address (0000000140001000 to 00000001400089AE)

So under this scheme, the first byte of the first section would be at
virtual address 0000000140001000 in the running process.

Later, ASLR came along and threw a wrench in all of that, and so these days
the image base is mostly meaningless.  The loader will probably never
actually load your module at the address specified in image base.  But the
rest of the rules still hold true.  Wherever it *does* load your module,
the first byte of .text will still be at offset 1000 from that.

So, if you want to return this value from the PE/COFF header, or even if
you want to return the actual address that the module was loaded at, then
no, it will never belong to any section (because the bytes at that address
will be the PE/COFF file header).

Does this make sense?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20181211/4604183d/attachment.html>

More information about the lldb-commits mailing list