xorbe <xorbe@xxxxxxxxx> writes:
> If this isn't the right mailing list, please just point me in the right direction.
>
> GLIBC has an allocated structure called _r_debug, of type B (bss) in ld-linux-x86-64.so.2, according to nm.
>
> The application's object file also seems to allocate _r_debug, of type C (common), according to nm.
>
> After the link, nm claims there is one symbol. However, in gdb, I can clearly see that there are two vastly different addresses both labeled as the _r_debug symbol. I got this from stepping into dl_main() / dl_debug_initialize(), and stepping into the application space where it attempts to access _r_debug. The application sees a blank structure naturally, as glibc initialized at the other location.
>
> (1) Why didn't the linker complain, and did it do something wrong here?
> (2) Or is the fault squarely on the provided application's object file?
>
> I altered the provided object file to rename the symbol as a short-term solution, but it would be nice to know the answer for sure, so I can file a proper application bug report knowing that I'm correct. ie, if they blame the linker, it would be helpful to clearly know why the linker isn't at fault here, because I'm pretty sure the answer is #2.
It might help to show a small example of what you mean.
I assume you are linking against glibc dynamically, as that is the
default. It is not an error for both the application and glibc to
define a global variable with the same name. That happens routinely
with dynamic linking. The dynamic library will normally have dynamic
relocations which cause the variable references in the library to be
redirected to the definition in the executable, in the case where the
executable defines the variable. That is what I see in
ld-linux-x86-64.so.2.
If I run this program:
#include <stdio.h>
int _r_debug;
int main() {
printf("%d\n", _r_debug);
}
it prints 1, which suggests to me that I am getting _r_debug defined in
ld-linux-x86-64.so.2. In other words, I do not see what you report.
To answer your specific questions: 1) the linker does not complain,
because this is a normal case; 2) I'm not sure there is any fault here.
Ian
