Re: binutils 2.20.1 on irix 6.5.22 _rld_new_interface question

[Richard Sandiford <rdsandiford at googlemail dot com>]

"David E. Cross" <crossd@cs.rpi.edu> writes:
>> Hi David,
>>
>> Thanks for the report.  It's good to hear that recent a GNU ld still
>> works reasonably well on IRIX 6.5.  It's many years since I last had
>> access to an IRIX box and tried this myself.  But there were quite
>> a few problems that needed to fixed around the 2.16 release, and I was
>> worried that might be true again now.
>>
>> "David E. Cross" <crossd@cs.rpi.edu> writes:
>>> Running binutils 2.20.1 on irix 6.5.22 with great success, moreso then
>>> native Irix ld in fact.
>>>
>>> However I have come across one bug that I am scratching my head over how
>>> to fix.
>>>
>>> Irix has no "dladdr" funtion, instead they tell you to call
>>> _rld_new_interface with certain parameters and it will do the same things.
>>> The problem is that _rld_new_interface is a special symbol that is within
>>> the runtime linker and not in any library.
>>>
>>> There is some special handling in bfd/elfxx-mips.c for this already, that
>>> ammounts to basically ignoring the symble.  This works fine for the 99% of
>>> applications that don't acually use the symbol (and allows things to link
>>> with libc).. However for programs that DO use it, a  undef symbol needs to
>>> be inserted into the symbol table as a placeholder.  Like _I THINK_
>>> is done with __rld_obj_head.  I have tried duplicating the part of the
>>> code that adds __rld_obj_head without success; (modifiying it to set
>>> BSF_FUNCTION and ST_FUNC).. I am obviously just stabbing in the dark here
>>> and I hope someone could help me out.. I have some symbol tables listed
>>> below:
>>
>> I think __rld_obj_head is a bit different.  IIUC, it's defined in crt1.o,
>> so is present in effectively all executable links.  (Please correct me
>> if I'm wrong on that.  Like I say, it's been a long time.)
>>
>> The add_symbol hack for _rld_new_interface is gross.  It looks like
>> it should only trigger for DSO inputs though.  If you have a regular
>> .o that references _rld_new_interface, it should get processed in the
>> normal way.
>
> Ok.. I am no ELF or linker ninja; so take everything with a rock of salt.
>
> I looked at crtbegin.o, crtend.o, irix-crti.o, and irix-crtn.o and none of 
> them have *rld* defined in them, it is mentioned in the irix ABI as one of 
> the "loader defined symbols" (as in _rld_new_interface).

Those are the GCC start and end files though.  The crt1.o that I mentioned
is part of IRIX (/usr/lib*/crt1.o, IIRC) and should get linked into every
executable.  That's the file that I thought mentioned __rld_obj_head.

> My _guess_ is that is what is happening in the current linker code (and 
> why).  libc.so.1 has an undefined reference to _rld_new_interface, this 
> prevented *all* code from linking when using gnu-ld, so a patch was put in 
> that basically ignored the libc.so.1 reference, pretend it doesn't exist.
>
> However in an object file that DOES refernce it, you have to list it (as 
> undefined) in the symbol table; ignoring it doesn't work (you have to 
> create the "hook" in the object table for the runtime linker to add a 
> symbol for; I *think* this is what __rld_obj_head is doing (but for a 
> "data" reference instead of a "text" reference).

But my point was that your use of _rld_new_interface seems to be coming
from a regular relocatable object (.o) -- namely dso_dlfcn.o -- rather
than a DSO (.so) input like libc.so.1.  The code in question is:

  if (SGI_COMPAT (abfd)
      && (abfd->flags & DYNAMIC) != 0
      && strcmp (*namep, "_rld_new_interface") == 0)
    {
      /* Skip IRIX5 rld entry name.  */
      *namep = NULL;
      return TRUE;
    }

and the (abfd->flags & DYNAMIC) != 0 check is supposed to restrict this
code to DSO inputs.  It shouldn't trigger for regular .o files like
dso_dlfcn.o.  So my guess was that the reference from dso_dlfcn.o gets
past this check, but there's some other failure that stops the relocations
against the symbol from being processed correctly.  I suppose something like:

  if (SGI_COMPAT (abfd)
      && strcmp (*namep, "_rld_new_interface") == 0)
    printf ("Keeping _rld_new_interface from %s\n", abfd->filename);

after the code above would verify this.

Perhaps the problem is that the check above is also skipping the
definition of the symbol (in libdl.so, or whatever), and thus the
linker has nothing to resolve the relocations against.  Try adding

      && sym->st_shndx == SHN_UNDEF

to the condition, i.e.:

  if (SGI_COMPAT (abfd)
      && (abfd->flags & DYNAMIC) != 0
      && sym->st_shndx == SHN_UNDEF
      && strcmp (*namep, "_rld_new_interface") == 0)
    {
      /* Skip IRIX5 rld entry name.  */
      *namep = NULL;
      return TRUE;
    }

>> >> Symbols from /lib32/libc.so.1: >>
>>> [Index]   Value      Size    Type  Bind  Other     Shndx   Name
>>>
>>> [6243]  |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |_rld_new_interface
>>>
>>>
>>> dso_dlfcn  (when linked with Irix ld)
>>>
>>> [46]    | 268438512|       0|FUNC |GLOB |DEFAULT  |UNDEF  |_rld_new_interface
>>>
>>> dso_dlfcn.o (when compiled with Irix cc)
>>>
>>> [6]     |         0|       0|FUNC |GLOB |DEFAULT  |UNDEF  |_rld_new_interface
>>>
>>>
>>> dso_dlfcn.o (when compiled with gcc)
>>>
>>> [11]    |         0|       0|OBJT |GLOB |DEFAULT  |UNDEF  |_rld_new_interface
>>
>> Could you also show the relocations against _rld_new_interface in
>> dso_dlfcn.o?  Like you say, the OBJT thing is a bit odd...
>
> Not sure what you are asking there; isn't that what I provided with the NM 
> dumps?  The OBJT thing is odd, however I also had it call 'puts' so I 
> could see what a function that it does know about looks like, and it looks 
> the same (and it links and runs), so I am not overly concerned.

The output above just shows the symbol table entry for _rld_new_interface.
If you're using readelf, you can get the relocations using:

    readelf --wide --relocs dso_dlfcn.o

(There's a way of doing it with IRIX elfdump too, if you prefer that,
but I can't remember the syntax now.)  I was just curious what
relocations (R_MIPS_*) you had against _rld_new_interface.

Thanks,
Richard