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

[Lukasz Stelmach <l.stelmach@samsung.com>]

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

It was <2023-05-15 pon 06:47>, when Palmer Dabbelt wrote:
> 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,

No, the file we dlopen is an executable meant to work standalone. We
dlopen it for testing and this setup has worked for us on different
platforms (armv7l, aarch64, x86). We MAY have not encoutered an error
because our glibc has been patched. I have to investigate the details as
Florian brough it to our attention that an error should be reported.

> 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.

Now that I know I should get an error I will look more closely to see
what is going on.

Thank you, everyone, for your comments. They will help me a lot.
-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]