This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Commit: PR 22875: Stop strip corrupting unknown relocs
On Mon, Mar 05, 2018 at 05:00:29PM +0000, Nick Clifton wrote:
> Hi Guys,
>
> >> Nevertheless it has caused failures with the new test case and the
> >> `mips64-openbsd' and `mips64el-openbsd' targets:
>
> Sorry - I did not not have those targets in my hit-list. I have now added them.
>
> > 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;
> > }
>
> I can confirm that this patch fixes the problem for the mips64-openbsd target.
> If you want I can check it in.
>
> >
> > 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
>
> That is most strange. The reloc values are being generate by the "dc.a" assembler directive
> which is supposed to generate a value that is the size of an address. (64-bits in this case).
Except that mips o64 results in dc.a being 32 bits.. See tc-mips.c
HAVE_64BIT_ADDRESSES. If that is indeed what is required for o64 then
the test should just be disabled for those mips targets.
> Are mips64el addresses big endian, despite data being little endian ? That would explain the
> discrepancy.
>
>
> > 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.
>
> Adding this fixes the problem:
>
> @@ -4112,7 +4114,8 @@ mips_elf64_write_rela (bfd *abfd, asection *sec,
> int_rela.r_addend = ptr->addend;
> int_rela.r_ssym = RSS_UNDEF;
>
> - if ((*ptr->sym_ptr_ptr)->the_bfd->xvec != abfd->xvec
> + if (! bfd_is_const_section ((*ptr->sym_ptr_ptr)->section)
> + && (*ptr->sym_ptr_ptr)->the_bfd->xvec != abfd->xvec
> && ! _bfd_elf_validate_reloc (abfd, ptr))
> {
> *failedp = TRUE;
Or the simpler patch of just testing the_bfd for NULL, and doing the
same in mips_elf64_write_rel too. However, that workaround results in
objcopy silently modifying the copied object file, which is why I
decided to not post a patch for this and leave it to Maciej to fix
properly.
--
Alan Modra
Australia Development Lab, IBM