Created attachment 9545 [details] elf file with .MIPS.abiflags section. objcopy fails when trying to adjust the lma of the section ".MIPS.abiflags" The relevant line: --change-section-lma .MIPS.abiflags-0x80000000 \ The error: BFD: hello_flash_physical.elf: warning: allocated section `.MIPS.abiflags' not in segment I thought this might be due to the period in the middle of the section name, I have tried: --change-section-lma ".MIPS.abiflags"-0x80000000 \ --change-section-lma '.MIPS.abiflags'-0x80000000 \ --change-section-lma .MIPS\.abiflags-0x80000000 \ all to no avail... $ objdump -h -w hello_flash.elf | grep MIPS 11 .MIPS.abiflags 00000018 9d002cd8 9d002cd8 00012cd8 Objcopy version is 2.24.90: GNU objcopy (Codescape GNU Tools 2016.05-03 for MIPS MTI Bare Metal) 2.24.90 Copyright (C) 2014 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. Full Command: objcopy --change-section-lma .bootflash-0xA0000000 \ --change-section-lma .exception_vector-0x80000000 \ --change-section-lma .text-0x80000000 \ --change-section-lma .init-0x80000000 \ --change-section-lma .fini-0x80000000 \ --change-section-lma .eh_frame-0x80000000 \ --change-section-lma .jcr-0x80000000 \ --change-section-lma .ctors-0x80000000 \ --change-section-lma .dtors-0x80000000 \ --change-section-lma .rodata-0x80000000 \ --change-section-lma .data-0x80000000 \ --change-section-lma .bss-0x80000000 \ --change-section-lma .startdata-0x80000000 \ --change-section-lma .MIPS.abiflags-0x80000000 \ pic32_hello_flash.elf pic32_hello_flash_physical.elf If I omit the change to .MIPS.abiflags all other sections LMA's get adjusted correctly. elf file is attached. Cheers, Neil.
Hi Neil, Is this actually an error ? According to the sources that I looked at(*) this message is actually a warning, not an error, and the objcopy does proceed correctly. The message itself is meant to be informatory - ie it is telling you that the .MIPS-abiflags section is allocatable (it has SHF_ALLOC flag set) but it is not covered by any of the memory regions described in the ELF program headers. Which means that *if* the file is loaded into memory using only the information in the program headers, then the .MIPS.abiflags section will be missed. Cheers Nick (*) - I am looking at the current binutils development sources. You reported this bug against the 2.24 sources, which are really quite old now. It may be that the "allocate section not in segment" message was an error back then. In which case you can probably solve the problem by upgrading to a newer set of binutils sources.
Thanks for looking at this Nick. Its a warning for me too and objcopy produces the resultant elf file but that section remains unchanged: 6 .jcr 00000004 9d002c78 1d002c78 00012c78 2**2 CONTENTS, ALLOC, LOAD, DATA 7 .ctors 00000008 9d002c7c 1d002c7c 00012c7c 2**2 CONTENTS, ALLOC, LOAD, DATA 8 .dtors 00000008 9d002c84 1d002c84 00012c84 2**2 CONTENTS, ALLOC, LOAD, DATA 9 .MIPS.abiflags 00000018 9d002c90 9d002c90 00042c90 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 10 .rodata 000004d0 9d002ca8 1d002ca8 00012ca8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 11 .data 000004a4 80001000 1d003178 00021000 2**3 CONTENTS, ALLOC, LOAD, DATA (The LMA for .MIPS.abiflags should be 0x1d002c90) I'll see if I can build a newer version from source and see if this issue persists. Neil
.MIPS.abiflags is moved out of the PT_LOAD segment that it belongs to, which is an error, especially since another PT_LOAD segment is not created to load it.
The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9933dc52736dd349503e00a68cd0b9be4388f5a9 commit 9933dc52736dd349503e00a68cd0b9be4388f5a9 Author: Alan Modra <amodra@gmail.com> Date: Fri May 11 14:34:48 2018 +0930 PR20659, Objcopy and change section lma failing Sections may well belong in multiple segments. The testcase in the PR saw an allocated section being assigned to an ABIFLAGS segment, then not being assigned to a LOAD segment because it had already been handled. To fix that particular problem this patch sets and tests segment_mark only for LOAD segments. I kept the segment_mark test for LOAD segments because I think there may otherwise be a problem with zero size sections. A few other problems showed up with the testcase. Some targets align .dynamic, resulting in the test failing with "section .dynamic lma 0x800000c0 adjusted to 0x800000cc" and similar messages. I've tried to handle that with some more hacks to the segment lma, which do the right thing for the testcase, but may well fail in other situations. I've also removed the tests of segment lma (p_paddr) and code involved in deciding that an adjusted segment no longer covers the file or program headers. Those test can't be correct in the face of objcopy --change-section-lma. It may be necessary to reinstate the tests but do them modulo page size, but we'll see how this goes. PR 20659 bfd/ * elf.c (rewrite_elf_program_header): Use segment_mark only for PT_LOAD headers. Delete first_matching_lma and first_suggested_lma. Instead make matching_lma and suggested_lma pointers to the sections. Align section vma and lma calculated from segment. Don't clear includes_phdrs or includes_filehdr based on p_paddr test. Try to handle alignment padding before first section by adjusting new segment lma down. Adjust PT_PHDR map p_paddr. ld/ * testsuite/ld-elf/changelma.d, * testsuite/ld-elf/changelma.lnk, * testsuite/ld-elf/changelma.s: New test.
Fixed.