This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: [MIPS] Drop .dynsym symbol ordering requirement and nullify DT_GNU_XHASH


On Wed, 29 Jan 2020, Rich Felker wrote:

> >  Also I'm not sure if that further complication is going to make things 
> > better, as then not only you'll have to handle the original SVR4 MIPS 
> > psABI binaries, but these new ones with explicitly relocated GOT as well.  
> > Which means more arcane platform code to maintain.  Why do you think it is 
> > going to be beneficial?
> 
> Where do you mean more code to maintain? On the side of tools
> generating binaries, it's not clear to me what the net effect is; you
> avoid the need for new MIPS-specific GNU hash code, but have to add a
> code path to avoid use of the existing MIPS-specific implicit GOT and
> generate normal GOT slots instead. On the dynamic linker side, no new
> code whatsoever is needed; it just works (even with versions of the
> dynamic linker from before it was added).

 Yeah, I guess dynamic loading could just work by chance with the two 
relocations; not that it was architected.

 However you do need to make a suitable change to the toolchain to be able 
to produce the modified ELF structure and then keep existing code as well 
for systems that require the old stuff.  Similarly to the current `-mplt' 
option and its `-mno-plt' counterpart, and all the resulting hairy bits 
especially in LD.

 Also as I say, that cannot handle the local part of the GOT, as we have 
no MIPS relocation to express the desired relocation by the base address, 
so you'll end up with hybrid images that are unlike other psABI stuff and 
not like regular MIPS psABI stuff either.

  Maciej


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