Looks pretty non-controversial. Does this fix anything? Seems like there should be a test that breaks somehow if this doesn't work. I don't know off the top of my head what the debugger command is "get the address of the entry point", but presumably it was broken before this patch?
ObjectFilePECOFF::GetEntryPointAddress() is not implemented correctly. See inlined comments.
|823 ↗||(On Diff #50075)|
You will need to convert the file address "m_coff_header_opt.entry" into a section offset address before returning this. See ObjectFileELF::GetEntryPointAddress() for info on how to do this correctly and also how to cache the entry address in case it is asked for multiple time. ObjectFileELF has an instance variable "Address m_entry_point_address;" that it will populate once and lazily and return it is we have resolved the address, otherwise it will resolve the file address using the section list.
lldb_private::Address is a section offset address class. We use section offset addresses everywhere. We also have the notion of three types of addresses: file address, load address and host address.
File addresses are virtual addresses as they are found in the object files (ELF, PECOFF, mach-o). They don't mean anything to the debugger because you will load your object file at various addresses as you are debugging. So we like to store the address as ".text + 0x123". Then when you load your shared library during runtime, the ".text" section will get slid by some offset. The target tracks where each shared library loads each of its sections and can turn a load address, or an address from a live process, into a section offset address. So load addresses can be resolved back into section + offset when running. A host address is when we stored constant data in the LLDB process itself. So in order to be able to slide your shared library around when running, we store all addresses as lldb_private::Address objects to facilite this. Targets can resolve a load address into a lldb_private::Address. When parsing things in object files, you must always translate any file addresses into lldb_private::Addresses (in symbols, debug info for functions and line entries, entry point addresses and much more).
Your function was causing an implicit constructor to be called on Address:
Address (lldb::addr_t abs_addr);
This will always result in a Address that has no section with an m_offset set to "abs_addr", meaning this is an absolute address that never slides.
We use the entry point address as the place to stop when we call functions by hand in the target. That's one place which is legit TEXT, but we are pretty sure the code you are calling will never call. So if the entry point address isn't set correctly we probably won't be able to call any functions by hand.
I was hoping there would be something like image headers that would just
display various information about the image, but it looks like we don't
have such a command that I can find. Seems like being able to find out the
entry point of a certain module would be useful.
FWIW, I didn't cache this value because in the current form it is just returning some data that is already cached by ParseHeader(). If I split it in section/offset address, it might be required.