This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Fwd: Issue with MIPS O32 FPXX, FP64 and FP64A ABI extensions
- From: Robert Schiele <rschiele at gmail dot com>
- To: Matthew Fortune <matthew dot fortune at imgtec dot com>
- Cc: binutils at sourceware dot org
- Date: Fri, 17 Jul 2015 08:26:06 +0200
- Subject: Fwd: Issue with MIPS O32 FPXX, FP64 and FP64A ABI extensions
- Authentication-results: sourceware.org; auth=none
- References: <CAObFj3yO0HokpLNChbvnj8oQ-P_6h-KMpOWZMNv2yBRpXYKZig at mail dot gmail dot com>
[Resending since the original one went out as an HTML email by
accident and thus got blocked. Sorry for that!]
Hi Matthew and all the other MIPS experts here,
I ran into a problem with your patch:
commit 351cdf24d223290b15fa991e5052ec9e9bd1e284
Author: Matthew Fortune <matthew.fortune@imgtec.com>
Date: Tue Jul 29 11:27:59 2014 +0100
[MIPS] Implement O32 FPXX, FP64 and FP64A ABI extensions
Specification:
https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
[...]
While the patch does not seem to cause issues when working with files
that were all created with a libbfd that had your patch applied there
seem to be some cases where this new code gets into trouble when it
has to deal with binaries created with a libbfd that did not have your
patch applied.
Specifically I ran into the problem when trying to strip a shared
library that was created before with an older binutils version and as
such did not have those extensions added to the binary.
The symptom basically is like this:
$ mips64-octeon2-linux-gnu-strip libfromoldbinutils.so
mips64-octeon2-linux-gnu-strip: stANZ6X0: Not enough room for program
headers, try linking with -N
mips64-octeon2-linux-gnu-strip:stANZ6X0[.MIPS.options]: Bad value
Some analysis on my side revealed the following: The code in
binutils/objcopy.c:copy_section seems to fail with the error message
above on whatever is the first section it finds if previously a new
PT_MIPS_ABIFLAGS segment was inserted by your new code in
bfd/elfxx-mips.c:_bfd_mips_elf_modify_segment_map. This code obviously
is triggered when processing binaries built with older binutils that
did not have those extensions and as such didn't have the segment
before. The situation that is identified as the problem by
bfd/elf.c:assign_file_positions_for_load_sections is that one here:
if (m->count > 0)
{
if (p->p_vaddr < (bfd_vma) off)
{
(*_bfd_error_handler)
(_("%B: Not enough room for program headers, try
linking with -N"),
abfd);
bfd_set_error (bfd_error_bad_value);
return FALSE;
}
p->p_vaddr -= off;
if (!m->p_paddr_valid)
p->p_paddr -= off;
}
I am not familiar enough with the details of that extension to decide
whether we need a special handling for operations like strip to skip
insertion of that segment or whether the segment actually always needs
to get inserted but some other part in the code needs to get modified
to deal with that situation properly.
Any input on that topic is obviously welcome.
Robert