Re: Another strike against ld -r

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Aug 11, 2004 at 04:49:08PM +0930, Alan Modra wrote:
> gcc -O2 -g -c undef1.c
> gcc -O2 -c undef2.c
> gcc -O2 -g -c undef3.c
> gcc -o undef undef1.o undef2.o undef3.o
> undef1.o(.toc+0x0): In function `foo':
> undef1.c:4: undefined reference to `bad1'
> undef2.o(.toc+0x0): undefined reference to `bad2'
> collect2: ld returned 1 exit status
> 
> All as expected.  undef2.c wasn't compiled with -g, so ld doesn't try
> to report function and line number for undef2.o.
> 
> Now look what happens if ld -r is involved.
> 
> ld -melf64ppc -r -o undef4.o undef1.o undef2.o
> gcc -o undef undef3.o undef4.o
> undef4.o(.toc+0x0): In function `foo':
> /src/tmp/undef1.c:4: undefined reference to `bad1'
> undef4.o(.toc+0x8):/src/tmp/undef1.c:5: undefined reference to `bad2'
> collect2: ld returned 1 exit status
> 
> Note how both undefined references are now in undef1.c:foo.

Interesting... on i386 (binutils 2.15) I get:
undef1.o(.text+0x2): In function `foo':
/home/drow/tes/undef1.c:4: undefined reference to `bad1'
undef2.o(.text+0x2): In function `bar':
: undefined reference to `bad2'

vs

undef4.o(.text+0x2): In function `foo':
/home/drow/tes/undef1.c:4: undefined reference to `bad1'
undef4.o(.text+0x12): In function `bar':
: undefined reference to `bad2'

Do the line tables have the DW_LNE_end_of_sequence?  Were they
generated with .loc manually by GCC?

> 
> This buggy ld behaviour was originally reported relating to a linux
> kernel build, where the file with the undefined reference happened to be
> assembly.

This isn't a strike against ld -r.  It's only a problem with ld -r for
the linker's error messages... it's just as much a problem with normal
linking for, say, GDB.  The final executable won't be able to tell the
difference between undef1's line numbers and the body of undef2 either,
most likely.  I ran into this last week in a more complicated test
where gas's automatic end-of-sequence markers at end of each section
weren't enough.  It looked like this:

int main()
{
  foo();
}

asm ("\
foo:\n\
	ret\n\
")

foo appears to be on the same line as the body of main according to the
debug info.

The solution to that related problem is to:
  (A) Add a .loc equivalent that can explicitly say "end of sequence"
  (B) Make GCC test for it and emit it

-- 
Daniel Jacobowitz