This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
I would call this ld.so's problem. It's failing to simulate program
loading as it intends to.
I don't think this is really a hard issue, since using ld.so this way is not a normal thing to do. AFAIK it's only used in the libc build, or in special situations by hand, or ldd. I doubt it really needs to have all the compatibility checks that vanilla running of executables should.
But it would still be necessary to recognize that situation in order to prevent the check from being executed since accessing the ELF header field would segfault. The only way I see is to compare the AT_ENTRY field with the _start address which basically tells you if the current auxv does belong to the executable or not.
That said, it seems like ld.so could fix this. i.e., update the auxv fields on the stack to point to where it's loaded the executable rather than to ld.so itself.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |