#69 Rev #4112 to as/z80/z80pst.c breaks existing code


In revision 4112
a change was made to sdcc/as/z80/z80pst.c which breaks
existing code.

The documentation for ASxxxx
states that when the ABS flag is specified for an area,
the OVR flag is automatically forced on at the same
time. The change in rev 4112 removes this behaviour,
which breaks the compilation of (at the very least) GBDK.

ABS is the Absolute flag, i.e. a given area must be
placed at a specific place in code memory. OVR is the
Overlay flag, which specifies that the code in a given
area overlays any code that's already in that block of
memory. ABS without OVR seems to be an invalid state --
the inverse of OVR is CON (contiguous), which puts code
after the previous instance of the section, i.e. not at
the given absolute position.

Workaround: Changing the code to use the flags
'(ABS,OVR)' works around the bug. Alternatively,
applying the patch (attached) to the SDCC source tree
will restore the old behaviour.

I'm not sure if this counts as a bug, but it certainly
breaks compilation of A LOT of old code...


  • Maarten Brock

    Maarten Brock - 2006-08-08

    Logged In: YES

    Hello Philip,

    I did this. It was my intention to give the user the
    ability to use both overlapping and non-overlapping
    abslotue sections. I do not see any reason why ABS must be
    OVR too. I was unaware this was documented behaviour but
    I'll have to change that too then.

    The real reason is I want to remove the necessity for
    including ISR prototypes in the C file containing main().
    To do this I need absolute sections for the interrupt
    vectors. But I also want a warning/error when two C files
    each create an interrupt vector for the same interrupt. So
    I need non-overlapping absolute sections.

    I assume your code is hand-written asm then. A good search
    & replace should solve your problem quickly. I doubt there
    is really A LOT of old code depending on this.


  • Philip Pemberton

    Logged In: YES

    Might be worth putting a note somewhere on the SDCC website,
    and updating the (6-year-old) documentation then.

    Yes, the code is hand-written assembler -- the CRT0 and
    driver code for GBDK. It has a jump table in CRT0 that
    handles calls to the different graphics drivers. Then when
    you need one of those drivers, it compiles it in. Not the
    best code in the world, and it's a bit hard to explain the
    hows and whys of it.

    It is easy to fix though - replace all the ".AREA _HEADER
    (ABS)" with ".AREA _HEADER (ABS,OVR)", and the one instance
    of ".AREA _SFR (ABS)" in font.ms with ".AREA _SFR
    (ABS,OVR)". It's just that it took a hell of a lot of
    debugging to find the issue - I eventually grepped the
    object files against each other (I thought it was a code-gen
    bug in the assembler) and found that the flags were wrong in
    the newly-compiled crt0/graphics/text display code.

  • Maarten Brock

    Maarten Brock - 2006-08-14

    Logged In: YES

    I've updated as/doc/asxhtm.html to reflect the current

    I'm sorry for the inconvenience I caused. I'm sure it was
    hard to find this issue.

  • Maarten Brock

    Maarten Brock - 2006-08-14
    • assigned_to: nobody --> maartenbrock
    • status: open --> closed-fixed

Log in to post a comment.