Another strike against ld -r

[Alan Modra]

Consider the following little testcase.

cat > undef1.c <<EOF
int foo (void)
{
  extern int bad1;
  return bad1;
}
EOF
cat > undef2.c <<EOF
int bar (void)
{
  extern int bad2;
  return bad2;
}
EOF
cat > undef3.c <<EOF
extern int foo (void);
extern int bar (void);

int main (void)
{
  return foo () + bar ();
}
EOF
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.

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

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre