[PATCH v1] ld/ELF: Add --image-base command line option to the ELF linker

[Alan Modra]

On Sat, Oct 26, 2024 at 12:34:12AM +0000, Hakan Candar wrote:
> I am in the process of writing an updated patch, I fixed tests for all
> targets except nds32le-linux-gnu, arc-linux-uclibc, and
> h8300-linux-gnu.
> 
> Only on targets nds32le-linux-gnu and arc-linux-uclibc, the paddr and
> vaddr of the data segment is different. I suspect this might be a bug.
> 
> Readelf output:
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD           0x000000 0x00120000 0x00110000 0x00094 0x00094 R   0x10000
>   LOAD           0x000094 0x00120094 0x00120094 0x00002 0x00002 R E 0x10000
>   LOAD           0x000098 0x00130098 0x00130098 0x00000 0x00000 RW  0x10000
> 
> Notice how the VirtAddr and PhysAddr of the first segment is different.
> This behaviour is always present, regardless if -Ttext-segment was
> specified or not.
> 
> I can fix the issue by changing the ldscripts of those two targets and
> adding `. = ALIGN(CONSTANT (MAXPAGESIZE));` over `.init` for
> SEPARATE_CODE, similar to how other targets handle this. After this
> is done, these targets behave like other platforms where paddr and
> vaddr is the same.
> 
> How may I continue? Should I change the test case from

Thanks for looking at the test results.  I just looked at one or two
FAILs and saw you had some easy fixes to make.  I'm OK with you
leaving these three target FAILs as they are, for someone to fix
later.

> "  LOAD +0x0+ 0x0*120000 0x0*120000 0x[0-9a-f]+ 0x[0-9a-f]+ R   .*"
> to
> "  LOAD +0x0+ 0x0*120000 0x[0-9a-f]+ 0x[0-9a-f]+ 0x[0-9a-f]+ R   .*"
> not accounting for the physical address, or should the test stay as is
> and a new bug report be opened for this problem?
> 
> Further, the h8300-linux-gnu target did not create two different
> segments (R) and (RX) when -z separate-code was specified. It acted as
> -z noseparate-code. I am thinking of adding this target as xfail.
> 
> Best regards,
> Hakan
> 
> On Friday, 25 October 2024 at 06:37, Alan Modra <amodra@gmail.com> wrote:
> 
> > On Fri, Oct 25, 2024 at 01:25:21AM +0000, hakan wrote:
> > 
> > > LLD has dropped the option -Ttext-segment for specifying image base
> > > addresses, instead forcing the use of the --image-base option for both
> > > ELF and PE targets. As it stands, GNU LD and LLVM LLD are incompatible,
> > > having two different options for the same functionality.
> > > 
> > > This patch enables the use of --image-base on ELF targets, advancing
> > > consistency and compatibility.
> > > 
> > > See: https://reviews.llvm.org/D70468
> > > https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#address-related
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=25207
> > > 
> > > Moreover, a new test has been added to ensure -z separate-code behaviour
> > > when used with -Ttext-segment stays the same. When this combination is
> > > used, -Ttext-segment sets the address of the first segment (R), not the
> > > text segment (RX), and like with -z noseparate-code, no segments lesser
> > > than the specified address are created. If this behaviour was to change,
> > > the first (R) segment of the ELF file would begin in a lesser address
> > > than the specified text (RX) segment, breaking traditional use of this
> > > option for specifying image base address.
> > > 
> > > ld/
> > > PR 25207
> > > * emultempl/pe.em: Remove redeclaration of --image-base.
> > > * emultempl/pep.em: Ditto.
> > > * emultempl/beos.em: Ditto.
> > > * ldlex.h (enum option_values): Move OPTION_IMAGE_BASE.
> > > * lexsup.c (ld_options): Add --image-base.
> > > (parse_args): On ELF, make --image-base follow -Ttext-segment behaviour.
> > > * ld.texi: Document the new option and re-define -Ttext-segment
> > > with established behaviour.
> > > * testsuite/ld-elf/pr25207.d: New file.
> > > * testsuite/ld-elf/pr25207.s: New file.
> > > * NEWS: Mention the new feature.
> > > 
> > > Tested on Linux x86-64, for ELF and PE targets.
> > 
> > 
> > The test needs some tweaking. Fix these fails then the patch is OK.
> > 
> > arc-linux-uclibc +FAIL: ld-elf/pr25207
> > bfin-linux-uclibc +FAIL: ld-elf/pr25207
> > h8300-linux-gnu +FAIL: ld-elf/pr25207
> > hppa64-linux-gnu +FAIL: ld-elf/pr25207
> > metag-linux-gnu +FAIL: ld-elf/pr25207
> > mips64-linux-gnuabi64 +FAIL: ld-elf/pr25207
> > mipsel-linux-gnu +FAIL: ld-elf/pr25207
> > mipsisa32el-linux-gnu +FAIL: ld-elf/pr25207
> > mips-linux-gnu +FAIL: ld-elf/pr25207
> > nds32le-linux-gnu +FAIL: ld-elf/pr25207
> > sparc64-linux-gnu +FAIL: ld-elf/pr25207
> > 
> > --
> > Alan Modra

-- 
Alan Modra