global pointer gets overwritten with dlopen(3) on RISC-V

[Palmer Dabbelt]

On Fri, 12 May 2023 08:13:10 PDT (-0700), fw@deneb.enyo.de wrote:
> * Lukasz Stelmach via Libc-alpha:
>
>> We've got a program (the testee) written in C that we test with another
>> one (a testing harness, the tester) written in C++ with gtest. So far,
>> so good. To make the testing and inspection of the internal state of the
>> testee easier the tester does not start the testee as a separate process
>> but loads it with dlopen(3) and calls the testee's main() function.
>
> We specifically disallow this in current glibc because it does not
> work in general—unless the application is really loadable as a shared
> object (compiled as PIC and linked with -shared).

Just popping back up here, as we got lost in the ABI discussions and 
were talking about it during the glibc patchwork call: essentially it 
boils down to us needing a more concrete reproducer for the bug.

If GP is used in a shared object then we've got a bug somewhere, 
probably the linker.  There's been some debate about what things like 
position independent mean in RISC-V land, so it's entirely possible 
there's something odd floating around here.  If you can reproduce that 
it's probably a bug, but probably a LD/LLD bug.

It sounds like there are no known bugs in glibc related to loading 
executables via dlopen(), as that doesn't work for any port due to a 
host of reasons (GP is just one of them).  We might have some bug 
floating around, RISC-V specific or otherwise, though.  If you have a 
reproducer for that then we can try and sort things out.

Thanks!