#3569 SDCC can not link all function from linked library file

[Deqing Sun]

I tried to use the new SDCC build for my Arduino setup and the linker can not link the library properly.

So I created a simplified setup. I created 2 c files with a function in each, generate rel file and link the 2 rel into a library. Then I tried to link the main.c calling the 2 functions, but only 1 of them can be linked.

Here are the commands I used with sdcc-snapshot-x86_64-apple-macosx-20230323-13911.tar

sdcc/bin/sdcc -c main.c main.rel
sdcc/bin/sdcc -c add1.c add1.rel
sdcc/bin/sdcc -c add2.c add2.rel
sdcc/bin/sdar -rc add.lib add1.rel
sdcc/bin/sdar -rc add.lib add2.rel
sdcc/bin/sdcc main.rel add.lib -o out.elf 

?ASlink-Warning-Undefined Global '_add1' referenced by module 'main'

[Deqing Sun]

The same code worked perfectly well with build 13407. The lib generated by 13911 can not be linked with 13407. with the same error.

?ASlink-Warning-Undefined Global '_add1' referenced by module 'main'

While using 13911 to link the lib and rel from 13407. The identical hex file can be generated but I got error

?ASlink-Error-<cannot open> : "main.lst"

[Philipp Klaus Krause]

I can reproduce the issue on Debian GNU/Linux testing on amd64 using current sdcc from trunk.

P.S.: To reproduce the issue it is necessary to add the two .rel files in different invokations of sdar. I do not see the error when using just one "sdcc/bin/sdar -rc add.lib add1.rel add2.rel". Despite "sdar -p" and "sdar -tv" showing no difference between the libraries created in two different ways (the actual .lib files are not identical, though).

P.P.S.: I wonder if this is due to rebasing our sdbinutils on a newer upstream GNU binutils last summer? In that case, @felixs might know more about it.

[Deqing Sun]

It should be related to sdbinutils . I've build multiple version of SDCC.

r13463 links OK.
r13464~r13474 has build error like

asxxxx.c: In function ‘asxxxx_bfd_is_target_special_symbol’:
asxxxx.c:1068:49: error: parameter name omitted
 1068 | static bool asxxxx_bfd_is_target_special_symbol(bfd *, asymbol *)
      |                                                 ^~~~~
asxxxx.c:1068:56: error: parameter name omitted
 1068 | static bool asxxxx_bfd_is_target_special_symbol(bfd *, asymbol *)

r13475 can be built but has the link error.

The commits were all about sdbinutils

[Felix]

Here's a patch.

The Issue is between asxxxx.c, and bfd_bread. bfd_bread now reports an error upon reading past the end of the archive. This situation messes up the file type detection in sdnm -s and in sdar -rc.

I think asxxxx.c needs some refactoring, but unfortunately, I don't know how to use bfd_bread as intended. Ignoring the error helps (bfd_error_invalid_operation) but with potential side effects...

[Philipp Klaus Krause]

I had a quick look at the patch. It doesn't look obviously wrong, the regression tests I tried still pass, and the use case originally reported here also appears to work now.
@deqing: Could you also test if this patch is sufficient for you?

[Deqing Sun]

I just compiled the newest source with the patch, it seems work with the simple test code I made.

I'll try again with my raspberry pi and automatic hardware test script 15 hours later.

[Deqing Sun]

I've use my automatic test jig and tested all examples in CH55xduino and they are worked well! Thanks.

I will update the toolchain when the patch is compiled in snapshots for all OSs.

[Felix]

Thanks for the feedback. This is now [r14052].