This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: [PATCH 1/2] Add support for O32 FPXX ABI
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, "macro at codesourcery dot com" <macro at codesourcery dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 23 Apr 2014 07:36:14 +0000
- Subject: RE: [PATCH 1/2] Add support for O32 FPXX ABI
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023534DAAAB at LEMAIL01 dot le dot imgtec dot org> <87a9c0xkje dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534DC37D at LEMAIL01 dot le dot imgtec dot org> <87ha655s3i dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023534DC8CF at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1404221703080 dot 27956 at digraph dot polyomino dot org dot uk>
Joseph Myers <joseph@codesourcery.com> writes:
> On Mon, 7 Apr 2014, Matthew Fortune wrote:
>
> > > What did you think about the idea of reusing the .gnu_attributes
> > > section data as the segment data? It seems simpler than the PT_NOTE
> format.
> >
> > I have no major objection. Slight concern over defining more of the
> > MIPS ABI around the 'gnu' vendor attributes which is a bit strange
> > given the MIPS architecture is not restricted to gnu tools. Having
> > said that, MIPS is already using these as critical parts of the ABI
> > and following it through to load time information as well then seems
> reasonable.
> >
> > In order to use the pre-existing section for GNU attributes I guess it
> > would need to become SEC_ALLOC and get associated with the new program
> > header. Perhaps call it PT_MIPS_ATTRIBUTES or PT_GNU_ATTRIBUTES if
> > this were done for all architectures. And then somehow get that to be
> > positioned immediately after the notes segment.
>
> Making an allocated segment for attributes was previously rejected; see
> references in <http://www.eglibc.org/archives/patches/msg01019.html>. I
> don't think anything significant has changed to affect that design
> principle.
Later in this thread Richard and I essentially re-did that entire discussion
and also rejected making an allocated attributes segment. The current plan
is to add a new section with a new segment/program header for MIPS ABI
flags. I'm calling it .MIPS.abiflags, at least for now, and this section
contains a versioned structure including various useful data about what
the binary is. I'm getting close to a patch to send for initial comments.
dl-load.c in glibc will need an extra hook adding to allow a port to act
upon custom program headers and read extra data from the DSO. The new
segment will be close to the program headers but may well be outside of
the statically determined size that dl-open reads to start with.
Regards,
Matthew