[llvm] [llvm-objcopy][ELF] Disable huge section offset (PR #97036)

[Djordje Todorovic via llvm-commits]

djtodoro wrote:

(copying comment from the issue itself)

Hi @MaskRay,

The idea is to assume that everything is placed at a certain address (let's say `0x40000000`), and then to declare a variable in a new named section using `__attribute__`, so if this section is not added to the linker script layout, it will be placed at VMA `0x0` along with debug and other non-allocated sections, even though it is allocated, resulting in a sparse binary.

I've managed to (somewhat) reproduce the problem with a simple case for the MIPS architecture:
```
$ cat ./linker.ld 
SECTIONS
{
  . = 0x40000000;
  .text : { *(.text) }
  .data : { *(.data) }
  .bss : { *(.bss) }

  /DISCARD/ : { *(.debug*) }
}
$ cat test.c
// Place this variable in a custom section
__attribute__((section(".custom_section")))
int my_variable = 0x12345678;

int main() {
    return 0;
}
$ mips-img-linux-gnu/2017.10-05/bin/mips-img-linux-gnu-gcc test.c -g -c -o main.o && mips-img-linux-gnu/2017.10-05/bin/mips-img-linux-gnu-ld -T linker.ld main.o -o main.elf
```
By default, we won't see the file truncated error report, since the section at a negative offset (".pdr") won't be loaded, so it is being ignored by objcopy.

```
$ mips-img-linux-gnu-objcopy -O binary main.elf test.bin
```
(even though the file position/offset is negative for the section: -1073741824).

But, if I add a load flag for the section it will be reported:

```
$ mips-img-linux-gnu-objcopy --set-section-flags .pdr=load -O binary main.elf test.bin
mips-img-linux-gnu-objcopy: test.bin[.pdr]: file truncated
```

This issue isn't just theoretical; it reflects a real use-case with one of our embedded targets. The `yaml2obj` tool was only used to create a problematic scenario for testing, but our actual use-case involves auto-generated linker scripts that result in such sections.

Given these practical implications, having an optional flag in `llvm-objcopy` to handle such cases would be beneficial. It would provide a straightforward solution for users facing similar issues without impacting the default behavior.

In embedded systems, size really matters, and the file truncated error from BFD (`bfd_error_file_truncated`) helps us detect potential file size increases that could be problematic.

Thanks again for your insights.



https://github.com/llvm/llvm-project/pull/97036