#1777 [z80] Linker map file has /0 instead of divusigned.rel
Compile the following file (div.c) using "sdcc -mz80 div.c":
==== begin div.c ====
int
do_div(int a, int b)
{
return (a/b);
}
int
main (void)
{
int a = 23;
int b = 3;
return (do_div(a, b));
}
==== end div.c ====
then inspect the div.map file. The following lines appear at in the "Libraries Linked" section:
Libraries Linked [ object file ]
/tmp/sdcc/bin/../share/sdcc/lib/z80/z80. [ divsigned.rel ]
/tmp/sdcc/bin/../share/sdcc/lib/z80/z80. [ /0 ]
Looking at the functions in the _CODE section, eliminating the contents of div.c and divsigned.rel, then matching up with other libraries which make up z80.lib, it appears the second library should be "divusigned.rel".
I've tried with the hc08 and mcs51, and neither of those seem to suffer the same problem (at least for the same library). Only the z80 library seems affected (although I can't say that no other library file/object file will show up the same symptom).
I can't spot any obvious difference between divsigned.s and divunsigned.s which might explain it (although if this were the case, I'd expect other ports to show the same symptom) so I presume this is buried somewhere in the library handling of the z80 port.
The version of ar used to generate the library is that included in Solaris 11 express:
$ /usr/bin/ar -V
ar: Software Generation Utilities (SGU) Solaris-ELF (4.0)
The above code fragment was compiled with sdcc 3.0.2 #6382, built on Solaris using GCC 4.3.
This is not a new problem. If I re-build an old copy of sdcc (2.9.7 #5973), I see the same behaviour in the z80 port.
Adding some debugging to the linker src, I notice it is the members of the archive with longer names which are affected:
divunsigned.rel
modunsigned.rel
printf_large.rel
It's not an 8.3 problem, as divsigned.rel is unaffected, but is 9.3 in length.
The library is built using Solaris's 'ar' command. Using GNU ar improves things slightly - most of them are now correct, but printf_large.rel still appears as "/0".
In all cases, "ar -t" of the archive (either version of 'ar') displays the filename correctly.
See http://www.regatta.cmc.msu.ru/doc/usr/share/man/info/ru_RU/a_doc_lib/files/aixfiles/ar_IA64.htm
"If an archive member's name is more than 15 bytes long, a special archive member contains a table of file names, each followed by a forward slash and a new-line character. This string table member, if present, precedes all "normal" archive members. The special archive symbol table is not a "normal" member and must appear first, if it exists. The ar_name field of the string table's member header holds a zero length name (ar_name[0]=='/'), followed by one trailing forward slash (ar_name[1]=='/'), followed by blanks (ar_name[2]==' ', and so on). Offsets into the string table begin at zero."
So obviously there is a bug in sdld which displays the ar_name instead of corresponding entry in the table of file names in the map file. Can you please attach to this bug tracker the z80.lib, generated on Solaris?
Borut
Borut
z80 lib compiled for SDCC #6382 on Solaris
I'd just reached the same conclusion. The ar.h(3HEAD) man page on Solaris states the same thing. File has been attached as requested.
I think I just saw this happen with mcs51 today too. I can attach the lib tomorrow if you like, but it was a standard, pretty recent snapshot build for windows.
I noticed that the libraries included in my own project didn't seem affected by this issue, despite having some long filenames in the archive.
Interestingly, if I create the z80.lib library using "ar -rS" instead of "ar -S -cq", it produces the correct results in the .map file. I'll attach this library too for comparison.
Z80 lib built with ar -rS for comparison
Further information - I don't think this is a linker bug. If I comment out the asranlib line from the Makefile, and leave the archive untouched, the names are correct. It seems like a bug in asranlib. The previously attached z80.lib which works was attached without asranlib being run on it. I've confirmed that an archive built with either -r or -q is OK as long as asranlib is not run, and either library will then "break" when asranlib has been run on it.
I already found out where the problem is. Brian, it is a linker problem, but it occurs only on asranlib-ed archives, as you already figured out. I already have a solution but it needs some additional polishing...
Brian & Maatren, thanks for your help.
Borut
Fixed in svn reviesion #6425.
Borut