#2970 Linker cannot find most symbols in libraries compiled with --debug

[David Grayson]

In recent versions of SDCC, sdcclib was removed, so I am trying to make my project use sdar instead. However, it seems that if I compile libraries using the --debug option, then the linker cannot find most of the symbols in those libraries. It only finds symbols in the first object file of the first library on its command line.

I use 5 very simple C files to reproduce this bug:

foo.c:

void foo() { }

bar.c:

void bar() { }

bat.c:

void bat() { }

mat.c:

void mat() { }

main.c:

void foo(void);
void bar(void);
void bat(void);
void mat(void);
void main() { foo(); bar(); bat(); mat(); }

Here is a shell script I run to reproduce the problem:

1 2 3 4 5 6 7 8 9 10

#!/usr/bin/bash set -ue sdcc -c main.c --debug sdcc -c foo.c --debug sdcc -c bar.c --debug sdar -rc foobar.lib foo.rel bar.rel sdcc -c bat.c --debug sdcc -c mat.c --debug sdar -rc batmat.lib bat.rel mat.rel sdcc --debug -o main.ihx main.rel foobar.lib batmat.lib

I would expect the script above to run silently and successfully. Instead, the script gives the following output:

C:\Program Files\SDCC\bin\sdar.exe: foo.rel:1: Unexpected character `\012' in asxxxx .rel file

C:\Program Files\SDCC\bin\sdar.exe: bar.rel:1: Unexpected character `\012' in asxxxx .rel file

C:\Program Files\SDCC\bin\sdar.exe: bat.rel:1: Unexpected character `\012' in asxxxx .rel file

C:\Program Files\SDCC\bin\sdar.exe: mat.rel:1: Unexpected character `\012' in asxxxx .rel file


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

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

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

Note that it finds _foo, which is in the first object file in the first library referenced in the final command, but it cannot find any of the other symbols referenced.

About my system: I am running SDCC on Windows 10 from an MSYS2/bash/MinTTY shell. The output of "sdcc -v" is:

SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ez80_z80/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15 4.0.0 #11528 (MINGW64)
published under GNU General Public License (GPL)

This bug makes it impractical for me to use SDCC 3.9.0 or later, so I hope someone can fix it! I suppose the first step is to look carefully at the files produced by sdar and determine if they are good. Thanks for the attention, and for fixing all the other bugs I have reported over the years!

[David Grayson]

I found a workaround for the bug. If I use dos2unix to convert the line endings in the .rel files to Unix-style line endings then everything works fine. Here is a script that builds the example program without any warnings or errors:

#!/usr/bin/bash
set -ue
sdcc -c main.c --debug
sdcc -c foo.c --debug
sdcc -c bar.c --debug
sdcc -c bat.c --debug
sdcc -c mat.c --debug
dos2unix *.rel
rm -f *.lib
sdar -rc foobar.lib foo.rel bar.rel
sdar -rc batmat.lib bat.rel mat.rel
sdcc --debug -o main.ihx main.rel foobar.lib batmat.lib

So the issue seems to be that sdcc is making object files with DOS-style line endings, and sdar is having trouble working with those files. I don't know why the issue only shows up with the --debug option though.

I would suggest that sdcc object files should always use Unix-style line endings. It seems like the object files don't have to be human readable (object files are usually binary anyway). Furthermore, since we live in a world where our computers can be connected in all sorts of ways, it seems anachronistic that text files would be encoded differently depending on what type of computer you happen to be using. That practice is likely to cause bugs like the one I'm reporting here, since it makes it harder to test your software on one OS and be sure it will work on another OS. The Unix-style line endings are shorter and hence simpler. They are also the standard for macOS and Linux. They are supported almost everywhere, including Notepad on Windows 10.

[Philipp Klaus Krause]

Thanks for looking into this. Most sdcc developers work mostly on GNU/Linux, so Windows-specific issuea are often problematic (we do have automated regression testing of Windows binaries - cross-compiling on GN/Linux and executing on wine, but it doesn't catch everything).

sdcc is quite old-style with separate preprocessor, compiler, assembler - the .rel files are created by the assembler, sdas, a fork of asxxxx. So this seems to be an issue in sdas.

[fruitCoder]

I ran also into this problem and I think David states correctly, it seems sdcc delivers a file with dos-style line endings therefor I guess its not a problem in sdas
Or, its how you see it sdar can't cope with dos style line endings or sdcc should not deliver files with dos style line endings..

[Sebastian Riedel]

The assemblers (sdas) are the ones that create the .rel files. They translate assembly into relocatible machine code.

[David Grayson]

I have attached a very simple patch I made to fix the issue. It makes the assembler open its output files in binary mode. This should have no effect in Linux, but on Windows it disables line-ending conversions, so the .rel file and other files emitted by the assembler end up with \n line endings.

I compiled the latest SDCC revision (11639) in Windows with MSYS2, checked that the bug was happening, and then recompiled it with this patch to make sure that the bug was fixed.

Can someone with authority please add this patch to SDCC?

[Philipp Klaus Krause]

It would be good if someone a bit familiar with the assembler / linker could have a look at this to check that
1) This doesn't cause regressions on other OSes
2) This is the right approach (I guess the alternative would be to make the linker able to handle DOS-style line endings) - which approach does newer upstream asxxxx take?

[Maximilian Gerhardt]

This problem also occurs for me in the latest SDCC 4.0 release on Windows 10.

[DeSh]

Same for me with SDCC 4.0 on Windows.

Do you have planns to fix it at all?

[Philipp Klaus Krause]

Since this is a major issue for some Windows users, I've just added it to the list at:
https://sourceforge.net/p/sdcc/wiki/SDCC%204.1.0%20Release/
That doesn't guarantee a fix, but increases the chance that someone looks into it before the 4.1.0 release a bit.

[Maximilian Gerhardt]

I'm still experiencing this issue in the 4.1.0 release on Windows 10 :( (https://github.com/platformio/platform-ststm8/issues/48#issuecomment-806846705)

[Philipp Klaus Krause]

I just tried with files as in the bug report and the script. It links fine for me on my Debian GNU/Linux testing system, so this is apparently really Windows-specific.

[Benedikt Freisen]

Are there any compatibility concerns that speak against applying the provided patch that changes exactly one character?
I am not aware of any other SDCC host platform that uses DOS line endings.

[Benedikt Freisen]

Patch applied in [r12963] with the addition of a comment that explains what is happening.