ld definitely not discarding unreferenced routines

ld definitely not discarding unreferenced routines

[Alex Buell]

Hi!

You might recall a few days ago that I posted with a problem regarding
discarding of unreferenced routines, I'm still seeing this happening. 

I'm using binutils 2.20.1 and NASM to build the boot block loaders. I
have taken what I've been working on and condensed them into a smaller
testcase. There are two binaries, part1.bin and part2.bin, one is a 16
bit boot loader whilst the other is a 32 bit protected mode boot loader.
Both reference routines held in a common library archive, created with
ar. 

In the common library archive (libcommon.a), there are two main
routines. One is 16 bit and the other is 32 bit. Linking part1.bin
should only pull in the 16 bit routine from the library, whilst linking
part2.bin should do the same for the 32 bit routine. 

Yet the linker is pulling in everything from the library archive, which
is the problem I've been experiencing with my project a few days ago
which makes the boot loader too big to fit into a 512 byte disk sector.
This can be seen in the map files generated. 

I have placed the testcase here at this URL:
http://www.munted.org.uk/programming/testcase.zip

I am not on the mailing list, so please take care to cc me when
replying. Thanks. 
-- 
http://www.munted.org.uk

One very high maintenance cat living here.

Re: ld definitely not discarding unreferenced routines

[Alan Modra]

On Sun, Jul 18, 2010 at 02:49:24PM +0100, Alex Buell wrote:
> In the common library archive (libcommon.a), there are two main
> routines. One is 16 bit and the other is 32 bit. Linking part1.bin
> should only pull in the 16 bit routine from the library, whilst linking
> part2.bin should do the same for the 32 bit routine. 

You put both functions in one object file.  ld extracts from archives
on a file by file basis to satisfy undefined symbols.  ld is working
exactly as designed.

If you must put both functions in one object file for some reason,
then you'll need to link with -gc-sections, *and* put the functions in
separate sections.  Garbage collection works on a section by section
basis.

-- 
Alan Modra
Australia Development Lab, IBM

Re: ld definitely not discarding unreferenced routines

[Alex Buell]

On Mon, 2010-07-19 at 10:45 +0930, Alan Modra wrote:

> On Sun, Jul 18, 2010 at 02:49:24PM +0100, Alex Buell wrote:
> > In the common library archive (libcommon.a), there are two main
> > routines. One is 16 bit and the other is 32 bit. Linking part1.bin
> > should only pull in the 16 bit routine from the library, whilst linking
> > part2.bin should do the same for the 32 bit routine. 
> 
> You put both functions in one object file.  ld extracts from archives
> on a file by file basis to satisfy undefined symbols.  ld is working
> exactly as designed.

So, ld actually works on a file by file basis instead of a routine by
routine basis? Won't unused routines get placed into the resulting
binaries regardless? 

In my old MS-DOS days we had extremely efficient linkers that discarded
unused routines, perhaps that's why I'm having trouble with this ;-)

> If you must put both functions in one object file for some reason,
> then you'll need to link with -gc-sections, *and* put the functions in
> separate sections.  Garbage collection works on a section by section
> basis.

I've been experimenting with --gc-sections (or is it -gc-sections, ld
actually doesn't complain) and with separate sections, but found this
doesn't actually work as the following map shows

.text           0x0000000000007c00       0xdf
 *(.text.unlikely .text.*_unlikely)
 *(.text .stub .text.* .gnu.linkonce.t.*)
 .text          0x0000000000007c00       0x35 part1.o
 .text.print16  0x0000000000007c35        0xe libcommon.a(io16.o)
                0x0000000000007c35                print16
 .text.print32  0x0000000000007c43       0x21 libcommon.a(io32.o)
                0x0000000000007c43                print32
 .text.putch32  0x0000000000007c64       0x48 libcommon.a(io32.o)
                0x0000000000007c64                putch32
 .text.movecursor32
                0x0000000000007cac       0x31 libcommon.a(io32.o)
                0x0000000000007cac                movecursor32
 .text          0x0000000000007cdd        0x2 libcommon.a(io32.o)

I just discovered that if I split the routines into their own files, I
can get exactly what I need.

Perhaps I'm missing something here...
-- 
http://www.munted.org.uk

One very high maintenance cat living here.