Menu
▾
▴
[sdcc-devel] [ sdcc-Bugs-3279445 ] [z80] Linker map file has /0 instead of divusigned.rel
|
From: SourceForge.net <no...@so...> - 2011-04-11 20:26:36
|
Bugs item #3279445, was opened at 2011-04-07 16:28 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3279445&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: z80 port Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Borut Ražem (borutr) Summary: [z80] Linker map file has /0 instead of divusigned.rel Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2011-04-11 22:26 Message: 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. ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-04-11 21:22 Message: 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. ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2011-04-11 20:39 Message: 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 ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2011-04-11 19:07 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3279445&group_id=599 |