This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Fwd: Issue with MIPS O32 FPXX, FP64 and FP64A ABI extensions


[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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]