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

[Zachary Turner via lldb-commits]

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
this:

Dump of file bin\count.exe

PE signature found

File Type: EXECUTABLE IMAGE

OPTIONAL HEADER VALUES
                  ...
       140000000 image base (0000000140000000 to 0000000140011FFF)
                  ...
SECTION HEADER #1
   .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>