[Lldb-commits] [lldb] Ensure that the executable module is ModuleList[0] (PR #78360)

[via lldb-commits]

jimingham wrote:



> On Jan 18, 2024, at 8:41 AM, Pavel Labath ***@***.***> wrote:
> 
> 
> Will the value of ObjectFile::GetType ever be meaningful, then?
> 
> It's partially meaningful. eTypeCoreFile, eTypeObjectFile and eTypeExecutable (when it is set) should mean what they say. The problem is with eTypeSharedLibrary (and to a lesser degree with eTypeDebugInfo). Just because an object is a shared library doesn't mean that it can be executed (as the main executable or the dynamic linker). It's not that these concepts don't exist, it's just that it's not possible to determine the role of a file in isolation. I don't think that was anyone's intention, it's just ELF (unlike, say, MachO) doesn't have the flags to differentiate these.
> 
> Do you change it after running based on what the loader tells you?
> 
> We don't, and I don't think we should, because that's about a role that the object plays in a specific process. In theory you could use that object in a different role in another process.
> 
> So long as ObjectFileELF::CalculateType never returns ET_EXEC, this won't be an issue. But if some ObjectFile that's not in fact the main binary says it has this type, not only will this change to Append not do the right thing, Target::GetExecutableModule will also return this module.
> 
> CalculateType() will return eTypeExecutable for ET_EXEC, which is used for non-position-independent executables, and I don't think you can load those as libraries (the dynamic loader will not let them. However, there is nothing stopping a user from adding that module manually (exactly like your test does) and that could mess things up a bit. Not too much, because (outside of Swift, I guess) we don't care that much about which module is the main executable, but it will confuse anyone who asks for it. To be honest, I don't particularly like this functionality of automatically shuffling module lists. I think it would be better to have separate API to set the executable module or tag an existing module as such. It's probably the only thing that can reliably work for elf, but I also think its clearer/more explicit in general.
> 
We have API to do both get and set main executable.  They currently find the first eTypeExecutable in the list and if there isn't one returns the first element in the list.  But before the Get was added we relied on the main executable being the first in the list. I didn't do an exhaustive search, but I couldn't find any places internally that just dial up the 0th element, what I could find uses the API's.  But we have said the main executable will be the first in the list through the SB API's.  We can decide we don't want to support that list ordering anymore, and you have to use the API.  But we try not to change things we've told people were true about the SB API's out from under them.

Jim
> —
> Reply to this email directly, view it on GitHub <https://github.com/llvm/llvm-project/pull/78360#issuecomment-1898837143>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUPVWYUIKWMTXJAWPXQ673YPFGERAVCNFSM6AAAAABB5SJJW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJYHAZTOMJUGM>.
> You are receiving this because you modified the open/close state.
> 



https://github.com/llvm/llvm-project/pull/78360