This is the mail archive of the
mailing list for the binutils project.
Re: PR 10629, mips irix6 assert and segfault
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: Alan Modra <amodra at gmail dot com>, <binutils at sourceware dot org>
- Date: Wed, 28 Nov 2012 22:16:18 +0000
- Subject: Re: PR 10629, mips irix6 assert and segfault
- References: <20091013231732.GM8054@bubble.grove.modra.org> <email@example.com> <alpine.DEB.firstname.lastname@example.org>
"Maciej W. Rozycki" <email@example.com> writes:
> On Thu, 15 Oct 2009, Richard Sandiford wrote:
>> Alan Modra <firstname.lastname@example.org> writes:
>> > I was looking at this PR the other day but soon realized I don't know
>> > enough about the mips ABIs to be confident of making a correct fix,
>> > and it doesn't help that www.mipsabi.org links to tech docs are all
>> > broken.
>> > The obvious problem leading to this pr is that
>> > _bfd_mips_elf_create_dynamic_sections does not create a .rld_map
>> > section when irix6 compatible, but a few lines later attempts to
>> > create a __rld_map symbol using the section. The segfault is easy to
>> > fix by not creating the symbol, but then, how does DT_MIPS_RLD_MAP get
>> > set for irix6?
>> Well, I looked at some ABI docs, and I can't figure it out either.
>> The only mention of rld_map in SGI's ELF64 ABI seems to be in a list
>> of dynamic tags. That list includes DT_MIPS_RLD_MAP as an optional tag,
>> but there seems to be no other mention of it in the rest of the document.
>> The implication is that this should be the same as for the 32-bit psABI,
>> which simply says that DT_MIPS_RLD_MAP points to a 32-bit data word that
>> is used for debugging, and that anything that relies on its value is not
>> conformant. (Usual standardese, of course, and this is no doubt a
>> 64-bit value in ELF64.) Nothing talks about the .rld_map section or the
>> __rld_obj_head symbol.
>> My only guess is that __rld_obj_head is normally defined for IRIX6,
>> which would circumvent the guilty code. That's hardly a good assumption
>> to make, but maybe we just got away with it. Mark's patch makes it clear
>> that on IRIX 6 (unlike IRIX 5), this symbol is not always in the
>> .rld_map section:
>> I don't know where it is instead though.
>> However, I do remember GAS and GNU ld worked well enough a few years
>> back to pass GCC testing (probably in the binutils 2.15 timeframe)
>> and I can't see anything obvious that has changed in the meantime.
>> Someone with IRIX access is probably going to have to fix this.
> While I do not qualify as I have no IRIX access, I triggered this problem
> with the mips-sgi-irix6 targets and the new test cases I have been working
> on, and to avoid adding dozens of new failures I spent a few moments
> looking into it. As a result I came across this:
> "SYSTEM DEVELOPER'S INTERFACE
> rld keeps a doubly linked list of structures. crt1.o contains a
> pointer, __rld_obj_head, to the head of the list of object structures.
> This pointer's targets depend on the ABI, as follows:
> * For an old 32-bit executable, __rld_obj_head points to a linked list
> of objList structures (/usr/include/obj_list.h). Each of these
> structures has a data element that is a pointer to a struct obj
> (/usr/include/obj.h), even though the field is not declared as a
> * For a new 32-bit executable, __rld_obj_head points to a linked list
> of Elf32_Obj_Info structures: /usr/include/objlist.h.
> * For a 64-bit executable, __rld_obj_head points to a linked list of
> Elf64_Obj_Info structures: /usr/include/objlist.h.
> The oi_magic element of each Elf32_Obj_Info or Elf64_Obj_Info is all-
> bits-on (0xffffffff) to make it easier to determine which list type in
> use is a 32-bit executable."
> in IRIX 6.5 rld(5) system manual . And it's not like that section of
> the manual slipped through the system update or suchlike as it includes
> explicit references to the n32 and n64 ABIs that were only added with IRIX
> 6 and not supported beforehand.
> So it looks like your guess is indeed correct and we should simply assert
> that just as with IRIX 5, the symbol is always present, and if not, then
> the binary is non-compliant and we can do whatever we see fit. And in the
> absence of the symbol we already add the .rld.map section to IRIX 5
> binaries, so I suppose the outcome is not going to be any worse if we do
> that for IRIX 6 too.
> Therefore I propose the change below to address this problem. This
> FAIL: reloc test 6b
> for mips-sgi-irix6 and causes no regressions across the list of my usual
> targets (whose count has now grown to 136). OK to apply?
> I'm not sure if the original submitter can be bothered anymore as he
> stopped responding even as the bug was being actively handled,
Yeah, it's probably time we put this port to bed. On the other hand,
the bfd vectors are used by other ports, so trying to remove code might
end up being more trouble than it's worth.
> but I think we can safely mark it PR ld/10629 and tick off.
Patch is OK, thanks.