#81 linker map file is pretty unreadable

Maarten Brock
Brian Ruthven

Sometime recently between #6382 and #6484, the linker .map file output changed. I'm only using the Z80 port, so for me, printing addresses as 32-bit values is both pointless and wasteful of space (although I suspect this is to support other architectures such as the Z180). Also, I notice we now get three columns instead of 1 in the .ABS. and _DATA sections, which sadly truncates heavily the symbol name. I'm left with examples like this:

00006307 _interrup | 00006307 _interrup | 00006351 _interrup

I'm guessing that this should be _interrupt_handler, _interrupt_handler_start and _interrupt_handler_end (as these are my symbols from the relevant assembler file), but they are next to useless without some guess work, or time-consuming cross-referencing with the .noi output file.

Finally, the hex numbers seem to be printed into a 16-character field, leaving 8 spaces, followed by 4 redundant zeros, followed by the value I'm interested in. Given each line wraps over the 80 column mark (which, judging from the rest of the output, it is not supposed to do), I suspect this is partly a format specifier error. This could also explain why the column headers don't line up with the values/symbols. Deleting 5 of the 8 spaces from each of the3 columns lines the up and makes the output fit in 80 chars again.

Actually, looking at the version of aslink included with SDCC #6382, the column headers didn't line up with the data generated, so this part is not new.

All of these are purely cosmetic, and although the symbol truncation is somewhat irritating, generating a .noi file is a relatively easy workaround for function/variable locations, etc...

Ideally, I'd like a linker flag which specified the width of values. By all means default to 32-bit, but something to lower this back to 16-bit or even raise to 64-bit(!) would be more flexible. [Not sure why you'd want 64-bit though...]

Likewise, if auto-widening the columns is non-trivial, a 1-column output flag would be useful too. cf. '-1' flag to /bin/ls on unix, or the /w switch to dir on MS-DOS (although this has the opposite effect IIRC).

For reference, I'm calling the Z80 linker manually:

$ sdldz80 -nf project.lnk

The project.lnk file has:
-i project
-b _CODE = _init_end
-k /tools/share/sdcc/lib/z80
-l ../common.lib
-l z80


( _init_end is defined in the custom crt, so that the _CODE section follows immediately after the crt code itself. )

Version of sdldxx:

$ sdldz80 -v
ASlink >> -v
Unkown option -v ignored <===== spelling error here too

sdld Linker V02.00 + NoICE + sdld


Version of SDCC this came from:
$ sdcc -v
SDCC : z80 3.0.2 #6484 (May 6 2011) (Solaris i386)


  • Maarten Brock
    Maarten Brock


    While trying to synchronize sdld with ASxxxx 5 I disabled the automatic wflag (wide output format) when compiled as sdld. So now SDCC always sets -w in the linker script. Since you do not use this generated linker script you need to specify it yourself in the project.lnk file.

    But beware, there are more changes in the flags. Please verify all flags with the new documenation.

    I moved this to Support Requests as that's probably what it is. I've also set it Pending your reply. If you think the matter can be closed, please update the status of this tracker item.


  • Maarten Brock
    Maarten Brock

    • labels: 355281 -->
    • assigned_to: nobody --> maartenbrock
    • status: open --> pending
  • Brian Ruthven
    Brian Ruthven

    OK Thanks. I'm going by the "doc" supplied in the sdcc-src tarball as sdas/doc/asmlnk.txt which doesn't mention this (not that I can see). I see the -w option is listed in the usage output, so I'll add that to my linker file. The columns still don't line up though ;-)

    One further nit, the description of the '-w' and the '-z' option in the sdldz80 usage is offset by 1 extra space.

    I presume sdld always reporting as V02.00 is intentional? I wonder if it's possible or even desirable to include some component of the underlying ASxxxx version number too? Just a thought.

    So, to summarise, I would see the outstanding issues as:
    1) usage descriptions don't all line up.
    2) column headers and values don't line up in map file.

    Both are cosmetic with no functional impact, so I've lowered the priority accordingly.

    Thanks for the reply.

  • Brian Ruthven
    Brian Ruthven

    • priority: 5 --> 2
    • status: pending --> open
  • Maarten Brock
    Maarten Brock

    As I'm still in the middle of the conversion from V2 to V5 I did not yet update the version number.

    I'll have a look at those columns later.

  • Maarten Brock
    Maarten Brock

    The columns are fixed in revision 6510.

  • Maarten Brock
    Maarten Brock

    • status: open --> closed