This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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]

Re: binutils 2.20.1 on irix 6.5.22 _rld_new_interface question


GNU ld works *very* well on irix 6.5.22; in fact I have to use it, since many programs compiled with GCC will choke with a "write past end of file" error when using Irix LD. Certainly around 2.16 it was a non-starter.. but now its very good, save this one issue (and there is a workaround, there's an option to ld to have it treat undefined symbols as warnings)

On Sat, 13 Nov 2010, Richard Sandiford wrote:

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

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

I think what needs to be done to "correctly" handle this, is to just add some phantom symbols at the beginning like I _think_ it is doing at line 6896 in elfxx-mips.c in the BFD library.

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


--
David E. Cross


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]