Page MenuHomePhabricator

Fix entry point lookup for ObjectFilePECOFF
Needs ReviewPublic

Authored by sas on Apr 27 2016, 10:36 AM.



Diff Detail

Event Timeline

sas updated this revision to Diff 55258.Apr 27 2016, 10:36 AM
sas retitled this revision from to Fix entry point lookup for ObjectFilePECOFF..
sas updated this object.
sas added a reviewer: zturner.
sas added a subscriber: lldb-commits.

+greg. I thought I remember Greg saying that that offsets were supposed to be RVAs, not VAs. Am I wrong here?

sas added a comment.Apr 27 2016, 11:02 AM

@zturner, you might be right, I might have to change the code I have to load the initial executable's Module and use an offset different than 0 there. I'll wait to see what @clayborg says.

clayborg edited edge metadata.Apr 27 2016, 1:02 PM

"offset" here must be a file address, or a virtual address as the file's sections know it. So if you take "offset" and look it up in the sections for the COFF file, it should be a correct address. I don't know what "m_coff_header_opt.image_base" is, but as along as entry + image_base is the address that should be looked up in the section list, then this would be correct.

image base is the address that the process should be loaded to in memory. But this is only a hint anyway, and a process might end up being loaded at a different address. So now that I think about it, this is wrong no matter what because even if you did want a virtual address, you would have to figure out the actual load address at runtime since it might not load at the desired address.

Let me clarify a few things. A "file address" is an address (lldb::addr_t) that gets translated into a section + offset address (lldb_private::Address which contains a lldb_private::Section + offset. Any addresses coming from ObjectFile parsers must be made into lldb_private::Address objects. As you load shared libraries and executables the dynamic loader plugins will tell the lldb_private::Target where all sections are loaded. So the slide is automatically applied to the section offset address. So you will make "m_entry_point_address" into something that says ".text + 0x123". If we ever want to use this address so set a breakpoint, we will resolve the lldb_private::Address into a "load address" (also a lldb::addr_t), but we will ask the target for foo.exe's ".text" load address, and we will get some slide address like 0x12340000 and then the load address would be "0x12340000 + 0x123", or 0x12340123. So each object file must encode their addresses correctly. Does that make more sense?

Example code to resolve this would be:

Address entry_addr = objfile->GetEntryPointAddress();

lldb::addr_t entry_load_addr = entry_addr.GetLoadAddress(target);

if (entry_load_addr != LLDB_INVALID_ADDRESS)
    // We were able to resolve the address as the target has the section loaded
    // The section is not loaded in the target yet. We might have a target that hasn't
    // been launched yet, the process might have exited, or the address might be
    // from a shared library that will get loaded later in the process' lifetime
zturner resigned from this revision.Jun 2 2016, 8:37 PM
zturner removed a reviewer: zturner.

Any progress on this? Read the previous comments and see if what I said makes sense.

Anyone still care about this? It would be nice to move it along or abandon it.

sas retitled this revision from Fix entry point lookup for ObjectFilePECOFF. to Fix entry point lookup for ObjectFilePECOFF.Oct 26 2017, 9:51 AM

Does this need some ARM support where we strip bit zero in case the entry point is Thumb?

sas added a comment.Oct 26 2017, 10:39 AM

Does this need some ARM support where we strip bit zero in case the entry point is Thumb?

Good question. Somehow we never had any issue with this but I don't remember explicitly checking for difference with thumb entry points either.

That being said, Winphone expects thumb-only for user-space code, so I'd assume m_coff_header_opt.entry does not include the thumb bit, but the kernel still jumps to user code in thumb mode.