Commit: PR 22875: Stop strip corrupting unknown relocs

Maciej W. Rozycki macro@mips.com
Fri Mar 23 00:34:00 GMT 2018


On Sun, 4 Mar 2018, Alan Modra wrote:

> >  Nevertheless it has caused failures with the new test case and the 
> > `mips64-openbsd' and `mips64el-openbsd' targets:
> > 
> > Executing on host: .../binutils/strip-new  -g tmpdir/bintest.o -o tmpdir/copy.o   (timeout = 300)
> > .../binutils/strip-new: tmpdir/bintest.o: unsupported relocation type 0xf1
> > .../binutils/strip-new: tmpdir/bintest.o: unsupported relocation type 0xf1
> > 
> > failed with: <.../binutils/strip-new: tmpdir/bintest.o: unsupported relocation type 0xf1>, expected: <.* bad value>
> > .../binutils/strip-new: tmpdir/bintest.o: unsupported relocation type 0xf1
> > FAIL: binutils-all/strip-13
> > 
> > which both default to the n64 rather than o32 or n32 MIPS ABI.
> > 
> >  Offhand the error message appears correct to me, and arguably more useful 
> > than ambiguous and rather cryptic "bad value".
> 
> You're supposed to get the "unsupported relocation" error as well as
> the "bad value" error.  The reason why that isn't the case for mips64
> is that the error status isn't propagated up the call chain.

 Hmm, the o32 MIPS target backend however does not issue the "unsupported 
relocation" error, and neither does the i386 target AFAICS.  It looks to 
me like the reason is these targets do not support the RELA relocation 
format, as further indicated by `readelf -r':

readelf: Error: Section 4 has invalid sh_entsize of 0000000000000000
readelf: Error: (Using the expected size of 12 for the rest of this dump)

and reject broken input outright, before even getting to relocation 
processing.  I think it is a bug in the test case, which should use the 
REL format for backends which require it (we could possibly check both for 
dual-format backends).  And then I think the test case should get updated 
to expect both errors, as now we get false positives for o32 MIPS and i386 
objects.  Better error reporting for the unsupported relocation format 
would be good having too.

> Something like the following ought to fix that.
> 
> diff --git a/bfd/elf64-mips.c b/bfd/elf64-mips.c
> index ea2e921..9501613 100644
> --- a/bfd/elf64-mips.c
> +++ b/bfd/elf64-mips.c
> @@ -3611,7 +3611,7 @@ mips_elf64_rtype_to_howto (bfd *abfd, unsigned int r_type, bfd_boolean rela_p)
>  	  _bfd_error_handler (_("%pB: unsupported relocation type %#x"),
>  			      abfd, r_type);
>  	  bfd_set_error (bfd_error_bad_value);
> -	  r_type = R_MIPS_NONE;
> +	  return NULL;
>  	}
>        if (rela_p)
>  	return &mips_elf64_howto_table_rela[r_type];
> @@ -3800,6 +3800,8 @@ mips_elf64_slurp_one_reloc_table (bfd *abfd, asection *asect,
>  	  relent->addend = rela.r_addend;
>  
>  	  relent->howto = mips_elf64_rtype_to_howto (abfd, type, rela_p);
> +	  if (relent->howto == NULL)
> +	    goto error_return;
>  
>  	  ++relent;
>  	}

 Thanks for fixing it.

> >  However I find it strange 
> > that the MIPS n64 ABI backend is the only one to give this different error 
> > message, despite that backends for the three MIPS ABIs are all structured 
> > similarly.
> 
> An even more strange fact is that mips64el-openbsd creates really odd
> relocs for the strip-13 testcase.  There seems to be a word swap..
> 
> Relocation section '.rela.text' at offset 0x90 contains 2 entries:
>     Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
> 0000000000000000  000000f100000000 R_MIPS_NONE           readelf: Error:  bad symbol index: 000000f1 in reloc
>                     Type2: R_MIPS_NONE      
>                     Type3: R_MIPS_NONE      
> 0000000000000000  0000000000000000 R_MIPS_NONE                               0
>                     Type2: R_MIPS_NONE      
>                     Type3: R_MIPS_NONE      

 Well, that's a consequence of how n64 MIPS psABI encodes relocation 
triplets:

typedef struct
  {
    Elf64_Addr r_offset;
    Elf64_Word r_sym;
    Elf64_Byte r_ssym;
    Elf64_Byte r_type3;
    Elf64_Byte r_type2;
    Elf64_Byte r_type;
    Elf64_Sxword r_addend;
  }
Elf64_Rela;

Again, I think it's up to the test case to get it right when encoding 
relocations manually.

> Oh, and the bad symbol index gets you a segfault on trying to run
> strip -g, at this line
>       if ((*ptr->sym_ptr_ptr)->the_bfd->xvec != abfd->xvec
> in elf64-mip.c:mips_elf64_write_rela.  the_bfd is NULL.

 Will look into it (including your observation downthread).

  Maciej



More information about the Binutils mailing list