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

[via lldb-commits]

jimingham wrote:

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.  I'm not sure this actually matters much on Linux.  For Swift we use the main executable because that has some info we need to reconstruct the swift debugging environment, so it's somewhat important for us.  But maybe it doesn't matter much for Linux.

But it would still be nice to know whether to take this return seriously or nowt.

Jim


> On Jan 17, 2024, at 9:37 AM, Jim Ingham ***@***.***> wrote:
> 
> Will the value of ObjectFile::GetType ever be meaningful, then?  Do you change it after running based on what the loader tells you?  If that's not meaningful, then we probably should have some "ObjectFile::TypeIsMeaningful" and gate all this logic on that as well.
> 
> Jim
> 
> 
>> On Jan 17, 2024, at 2:43 AM, Pavel Labath ***@***.***> wrote:
>> 
>> 
>> The problem is that linux/elf does not really have hard line between shared libraries, (position-independent) executables and the dynamic linker. they all have e_type = ET_DYN in their header. It is possible to create a shared library that can also be executed (unless one is extremely careful it will crash very quickly, but that crash may exactly be something that one may want to observe in a debugger). It's probably also possible to create a library that will also serve as the dynamic loader.
>> 
>> So, the "is this module an executable" question is not really well defined. This isn't an intrinsic property of the module, but rather a role that the module plays in a specific process. Once a process starts, this can be (and is) determined by the dynamic linker plugin. Before that, we need to rely on some external signal for that (if we need to know that at all).
>> 
>> With that in mind, I'm going to disable the before-run part of the test for elf.
>> 
>> —
>> Reply to this email directly, view it on GitHub <https://github.com/llvm/llvm-project/pull/78360#issuecomment-1895545550>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUPVW42U6NY5I32YXSSGLLYO6TNDAVCNFSM6AAAAABB5SJJW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJVGU2DKNJVGA>.
>> You are receiving this because you modified the open/close state.
>> 
> 



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