Linker doesn't error out when only linking libraries containing incomplete object code.

[foss-for-synopsys-dwc-arc-processors]

Linker doesn't error out when only linking libraries containing incomplete object code.

[amylaar]

bad object files in a library will not report any problems during link stage, and the linker still generates all the output files.

That is the expected behaviour.

In fact, you can have object files for different architecture variants or even different architectures in a library,
and even documentation files, and as long as you only pull in compatible object files, it works.

So this is a request for new functionality, which could break some existing use cases.

[simonpcook]

In this case, what do you mean by a "bad object file", and does it just happen to live in the same library or is it an object being used from the library, as if it is the latter it may actually be a bug.

[rmbusy]

Sorry, "bad object file" was not good terminology. I should say "incomplete object files", meaning if there are missing symbols/code, the linker will not complain, will generate all the output files with no warnings or errors. To me, that is a bug.

[rmbusy]

Ignore the closed/open thing, I thought it was 'submitting' my comments. Updated the title to better reflect the issue.

[amylaar]

Well, the liker couldn't tell if code is missing. Missing symbol definitions are a different matter.
Are you saying that you have a case where the output contains non-weak references
to undefined symbols, without instructing the linker to do a relocatable link?

[rmbusy]

If I understand your question correctly, the answer is yes.

If there are unresolved symbols, the link should fail, as it does when the objects are passed directly to the linker. In the case where all the same code has been placed into a library, this doesn't fail, and all the output files are created with no warnings or errors.

[amylaar]

If an input file in an archive is not needed to resolve other symbols in object files that are already included in
the link, the linker won't include it, and thus any unresolved symbols in that left-out file will be irrelevant.
If you want to include every single object file inside an archive, you can specify this with the --whole-archive
option to ld before the library that you want to be treated as such. Use --no-whole-archive to turn off the
effect of that option for subsequent libraries. (When using the gcc compiler driver, you can use -Wl, to
pass options to the linker.)

[rmbusy]

The issue reported has nothing to do with unused objects in a library, or unused symbols in a object in a library. The issue is when there is an unresolved symbol that is required to link, that is MISSING from the files in the library (i.e. not in the library). In that case, the linker does not report any errors or warnings, and generates worthless / broken output files. Is that the expected behaviour?

[amylaar]

Please provide a test case. I.e. a set of object files (if required) and libraries, and the link command line
to create the broken output file from these input files.

[jeremybennett]

Hi rmbusy,

Thanks for all the explanation. A test case would really help us get to the bottom of the problem.

There is a known (generic) issue in this area, with weak symbols in a static library (i.e. symbols which are only to be linked if they are referenced, and there is not an alternative definition elsewhere). The linker will not bring such symbols in when the reference is from another object file in the library, and you end up with invalid object code.

Here is an example. It's run here on my Intel workstation, but it happens with every GNU tool chain I have tried. Take three files, main.c:

  extern int foo ();

  int
  main ()
  {
    return foo ();
  }

foo.c:

extern int bar () __attribute__ ((weak));

int
foo ()
{
  return bar () + 1;
}

bar.c:

int
bar ()
{
  return 1;
}

Compile foo.c and bar.c into a library, doit. Then compile main.c linking in doit

rm -f libdoit.a foo.o bar.o main
gcc -static -c foo.c
gcc -static -c bar.c
ar -rcs libdoit.a foo.o bar.o
gcc -static -o main main.c -L. -ldoit

Running causes a segmentation fault:

$ ./main
Segmentation fault

Running under GDB shows the linker has not been resolved the reference to bar(), even though there is a definition in the library.

(gdb) r
Starting program: /home/jeremy/tmp/arc-155/simple-demo/main 

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x08048cfb in foo ()
#2  0x08048ceb in main ()
(gdb) 

This is a widely encountered problem, but it is not a bug. Weak symbols are a GNU extension to C, and this is how they are supposed to work. See for example the discussion at http://glandium.org/blog/?p=2388.

I'm not sure if this is your problem, but a test case will allow us to check this.

HTH,

Jeremy

[rmbusy]

Thanks for the information Jeremy, and the seed for a test case. In my case, I'm not using "attribute weak", and in the test case I did not use "-static" (although in my app build, I am using -Bstatic). The good news is I see that my native binutils (ld) has the same issue, so it doesn't appear to be a port specific bug (should have tested this earlier). Given that, I'll close this issue.

In my case, I'm calling arc-elf-ld directly, not through gcc. If I link by calling gcc, I don't see the failure (i.e. it reports the missing symbol). Also, the command lines were a little different. Using your example .c files above without the weak attribute, I do the following :

gcc -c main.c
gcc -c foo.c
gcc -c bar.c
ar -rcs libdoit.a main.o foo.o bar.o
ld -o main_1.out -L. -ldoit -e 0
objdump -S main_1.out > main_1.sym

(now delete an object file and retest)
ar -d libdoit.a bar.o
ar -t libdoit.a (verify bar.o has been deleted)
ld -o main2.out -L. -ldoit -e 0
objdump -S main_2.out > main_2.sym

I expected the second link to fail because the symbols from bar.o were not present, but it does, without any complaints. Our build setup is fairly complicated, which is why I'm calling each of the tools directly. I'll revert back to calling gcc for the link phase now that I have everything building, which will allow me to use libraries again with some confidence.

[jeremybennett]

Hi rmbusy,

Glad this has cleared things up from you. It is generally a good idea to link compiled C using gcc rather than ld. If you run gcc -v, you will see the ld command line that is generated, which has a lot of extra libraries, code and options.

Best wishes,

Jeremy