Bug 32461 - ld: unrecognized option '--image-base=0x08148000'
Summary: ld: unrecognized option '--image-base=0x08148000'
Status: RESOLVED DUPLICATE of bug 25207
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.43.1
: P2 normal
Target Milestone: 2.44
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-12-15 21:17 UTC by Stas Sergeev
Modified: 2024-12-19 19:53 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stas Sergeev 2024-12-15 21:17:46 UTC
$ ld --image-base=0x08148000
ld: unrecognized option '--image-base=0x08148000'

Works (and produces the expected output
when given object files) with ld.lld.
man page documents this option.

Note that ld.lld says that using
-Ttext-segment instead of --image-base
is invalid.
Comment 1 Andreas Schwab 2024-12-15 21:41:35 UTC
[This option is specific to the i386 PE targeted port of the linker]
Comment 2 Andreas Schwab 2024-12-15 21:48:17 UTC
You need to select the i386pe or i386pep emulation to enable the option.

$ ld -m i386pe --image-base=0x08148000
ld: no input files
Comment 3 Stas Sergeev 2024-12-15 21:48:50 UTC
OK, thanks.
But what to do?
Use different opts on ld and lld?
lld says using -Ttext-segment is invalid,
and I also suspected the same, because
when I read segments with `readelf -l`,
I see that

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x08148000 0x08148000 0x0011c 0x0011c R   0x1000
  LOAD           0x001000 0x08149000 0x08149000 0x000c5 0x000c5 R E 0x1000
  LOAD           0x000000 0x0814a000 0x0814a000 0x00000 0x00018 RW  0x1000
  NOTE           0x0000f4 0x081480f4 0x081480f4 0x00028 0x00028 R   0x4
  GNU_PROPERTY   0x0000f4 0x081480f4 0x081480f4 0x00028 0x00028 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10

 Section to Segment mapping:
  Segment Sections...
   00     .note.gnu.property 
   01     .text 
   02     .bss 
   03     .note.gnu.property 
   04     .note.gnu.property 
   05

text segment is 1, so 0 will probably
not move?
What would be the portable way of
setting the image base?
Comment 4 Stas Sergeev 2024-12-15 22:07:48 UTC
Why not to stay compatible with
lld here? It seems to be doing the
right thing, at least in my understanding.
So while its definitely up to you,
I really suspect that closing this
ticket is sub-optimal.
Comment 5 H.J. Lu 2024-12-17 19:40:03 UTC
Fixed for 2.44 by

commit f4e363cae297ec3e24dec0d95f3d422879f498a3
Author: Hakan Candar <hakancandar@protonmail.com>
Date:   Mon Oct 28 11:01:59 2024 +0000

    ld/ELF: Add --image-base command line option to the ELF linker
    
    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.
Comment 6 Stas Sergeev 2024-12-17 20:24:46 UTC
Thanks!
Comment 7 H.J. Lu 2024-12-19 19:53:50 UTC

*** This bug has been marked as a duplicate of bug 25207 ***