ld -r

[Paul Edwards]

Hi Nick.

Thanks for your reply. Sorry about the delay.

My actual use is a customized GCC 3.2.3 and a
customized binutils 2.14a.

I can't use pie:

gcc386 -fpie -S -Os -fno-common -D__PDOS386__ -D__32BIT__ -I. -I../src -o 
pdptest.s pdptest.c
pdptest.c:0: unrecognized option `-fpie'

I can't really use pic:

gcc386 -fpic -S -Os -fno-common -D__PDOS386__ -D__32BIT__ -I. -I../src -o 
pdptest.s pdptest.c
as386 -o pdptest.o pdptest.s
...
pdptest.s:73: Error: cannot represent relocation type BFD_RELOC_386_GOTOFF
pdptest.s:78: Error: cannot represent relocation type BFD_RELOC_386_PLT32


And even if that did work, I don't think that's what I want.

Actually ld386 -r gives me exactly what I want, an O_MAGIC
a.out file. The only problems are:

1. No reporting of undefined symbols (I can work around
this by doing two links, the first without "-r" to report
the undefined symbols, before my real link).

2. The executable is a bit larger than I expected. Maybe
20% or so. But that may be due to "ident" strings, I'm
not sure. And either way, I can work around the problem
by just ignoring it.

3. I need t run a separate "strip" command to delete
some stuff I don't want, ie:
strip386 --strip-unneeded pdptest.exe


I know that the .o and .a files I am currently producing are
good enough to do the job, because I'm already using them
successfully. The information required to produce the a.out
file I want is already there. I just want ld386, maybe in
combination with something else, to produce the executable,
reporting unresolved errors, and of the proper size, and
preferably stripped.

Today I saw there was a "-N" option which looked promising,
but for some reason it set the text relocations and data
relocations to 0 (see offset 0x18 and 0x1c). Adding "-q"
didn't help either.

ld386 -N -s -e ___pdosst32 -o pdptest.exe pdosst32.o pdptest.o pdos.a
C:\devel\pdos\pdpclib>hexdump pdptest.exe 0 50
000000  07016400 086B0000 F8060000 B0670000  ..d..k.......g..
000010  00000000 00000000 00000000 00000000  ................

Note that without "-N" it produces N_MAGIC, which
is not what I want.

Here is what a good executable looks like, and you
can see there is data in 0x18 and 0x1c:

  ld386 -s -e ___pdosst32 -o pdptest.exe pdosst32.o pdptest.o pdos.a
  ld386 -r -s -e ___pdosst32 -o pdptest.exe pdosst32.o pdptest.o pdos.a
  strip386 --strip-unneeded pdptest.exe

C:\devel\pdos\pdpclib>hexdump pdptest.exe 0 50
000000  07016400 086B0000 F8060000 B0670000  ..d..k.......g..
000010  00000000 00000000 50120000 70000000  ........P...p...


Note that a.out is the format I have been producing
for something like 25 years, using EMX 0.9d. But I
have switched to my own builds running under
Windows a few years ago.

If there is no option to "ld" in binutils 2.14a to do what
I want, is there something I can change in the binutils
2.14a source code to make "ld" report unresolved
externals when "-r" is used?

Or to fill in the text and data relocations when "-N" is used?

Thanks. Paul.




-----Original Message----- 
From: Nick Clifton
Sent: Monday, May 11, 2020 9:35 PM
To: Paul Edwards ; binutils@sourceware.org
Subject: Re: ld -r

Hi Paul,

> Why does adding "-r" to "ld" allow the link
> to complete without error, even when there
> are undefined symbols?

Because the "-r" option tells the linker to perform a partial
link, not a full link.  It combines together the input files
into a single output file, but this output is not a functioning
binary yet.  It still needs a final link, which includes references
to the appropriate libraries and other object files, in order
for an executable to be produced.


> Is there an option I
> can use to get the link to fail as expected?

Just do not use the "-r" option.


> Note that I am using "-r" to produce
> relocatable executables. See below for example.

Unfortunately that is not the purpose of this option.

If you do not need to control the linker directly then using gcc to
perform the compilation and link is a much easier way to go.  For
example:

  gcc -fpic main.c

Note that you usually need to provide an option to gcc to tell it
that you want to produce a relocatable executable.  In the above
example -fpic is used.

If you do need to control the linker directly then normally no
special options are needed to make a relocatable executable.
Provided that you have compiled the code with the -fpic or -fpie
options then a relocatable program should be produced.  If you
are trying to build a relocatable library however then you do
need to give the linker the "-shared" command line option.

Cheers
  Nick