Bug 1463 - MIPS prelinking with latest compiler produces warnings/errors
Summary: MIPS prelinking with latest compiler produces warnings/errors
Status: RESOLVED FIXED
Alias: None
Product: Cross-prelink
Classification: Yocto Project Subprojects
Component: cross-prelink (show other bugs)
Version: unspecified
Hardware: x86 mips
: Medium normal
Target Milestone: 1.2
Assignee: Mark Hatle
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2011-09-08 08:54 UTC by Mark Hatle
Modified: 2012-01-25 08:24 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Hatle 2011-09-08 08:54:52 UTC
When prelinking against executables produce with the latest compilers, a number of warnings/errors are produced that indicate that section ordering does not match the prelinker's expectations.

The error message is:

NOBITS section followed by non-NOBITS section in the same segment

In order to reproduce the issue.  Use oe-core or Yocto Project to build a mips target image with the prelinker enabled.  Look at the temp/log.do_rootfs file for the error messages.

The error is traced down to the code:


exec.c:

        for (j = 1; j < dso->ehdr.e_shnum; ++j)
          if (dso->shdr[j].sh_addr >= dso->phdr[i].p_vaddr
              && dso->shdr[j].sh_addr + dso->shdr[j].sh_size
                 <= dso->phdr[i].p_vaddr + dso->phdr[i].p_memsz)
            {
              if (dso->shdr[j].sh_type != SHT_NOBITS
                  || (dso->shdr[j].sh_flags & SHF_TLS))
                {
                  if (sfirst)
                    {
                      error (0, 0, "%s: NOBITS section followed by non-NOBITS
section in the same segment",
                             dso->filename);
                      goto error_out;
                    }
                  continue;
                }

              if (!sfirst)
                sfirst = j;
              if (strcmp (strptr (dso, dso->ehdr.e_shstrndx,
                                  dso->shdr[j].sh_name), ".plt") == 0)
                slast = j + 1;
              else if (j == new_dynbss || j == new_sdynbss)
                slast = j;
            }

It loops over the sections, and if there is a PROGBITS and other sections after
non-NOBITS it throws an error.

All of the executables being produced by the latest toolchains look like:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        00400134 000134 00000d 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            00400144 000144 000020 00   A  0   0  4
  [ 3] .dynamic          DYNAMIC         00400164 000164 0000d8 08   A  6   0  4
  [ 4] .hash             HASH            0040023c 00023c 000f94 04   A  5   0  4
  [ 5] .dynsym           DYNSYM          004011d0 0011d0 001540 10   A  6   1  4
  [ 6] .dynstr           STRTAB          00402710 002710 000b75 00   A  0   0  1
  [ 7] .gnu.version      VERSYM          00403286 003286 0002a8 02   A  5   0  2
  [ 8] .gnu.version_r    VERNEED         00403530 003530 000080 00   A  6   1  4
  [ 9] .init             PROGBITS        004035b0 0035b0 000078 00  AX  0   0  4
  [10] .text             PROGBITS        00403630 003630 090450 00  AX  0   0 16
  [11] .MIPS.stubs       PROGBITS        00493a80 093a80 001280 00  AX  0   0  4
  [12] .fini             PROGBITS        00494d00 094d00 000044 00  AX  0   0  4
  [13] .rodata           PROGBITS        00494d50 094d50 010631 00   A  0   0 16
  [14] .eh_frame_hdr     PROGBITS        004a5384 0a5384 00002c 00   A  0   0  4
  [15] .eh_frame         PROGBITS        004a53b0 0a53b0 000068 00   A  0   0  4
  [16] .ctors            PROGBITS        004b5418 0a5418 000008 00  WA  0   0  4
  [17] .dtors            PROGBITS        004b5420 0a5420 000008 00  WA  0   0  4
  [18] .jcr              PROGBITS        004b5428 0a5428 000004 00  WA  0   0  4
  [19] .data.rel.ro      PROGBITS        004b542c 0a542c 000c48 00  WA  0   0  4
  [20] .data             PROGBITS        004b6074 0a6074 00013a 00  WA  0   0  4
  [21] .rld_map          PROGBITS        004b61b0 0a61b0 000004 00  WA  0   0  4
  [22] .got              PROGBITS        004b61c0 0a61c0 000568 04 WAp  0   0 16
  [23] .sdata            PROGBITS        004b6728 0a6728 000004 00 WAp  0   0  4
  [24] .sbss             NOBITS          004b672c 0a672c 00003d 00 WAp  0   0  4
  [25] .bss              NOBITS          004b6770 0a672c 0021cc 00  WA  0   0 16
  [26] .gnu.attributes   LOOS+ffffff5    00000000 0a672c 000010 00      0   0  1
  [27] .mdebug.abi32     PROGBITS        004b893c 0a673c 000000 00      0   0  1
  [28] .gnu_debuglink    PROGBITS        00000000 0a673c 00000c 00      0   0  1
  [29] .shstrtab         STRTAB          00000000 0a6748 00010d 00      0   0  1
Comment 1 Mark Hatle 2012-01-03 10:34:24 UTC
This is still an ongoing issue.

I believe the generated code from the linker is correct, but I'm not sure yet how to either change the linker ordering or update the prelinker to support this unique ordering.
Comment 2 Mark Hatle 2012-01-05 11:40:47 UTC
A possible fix for this issue has been sent to the oe-core mailing.
Comment 3 Mark Hatle 2012-01-13 09:42:23 UTC
Fix has been pushed to the cross-prelink repository.  An update to the prelink recipe is pending.

cross-prelink commit id: 7b47f2f8a15ed13b7905bc120bb2586f3e164f7d
Comment 4 Mark Hatle 2012-01-25 08:24:28 UTC
Fixed - oe-core commit: 09a70c55e590d169b8a3b4b89853c96b7b977fc0