#177 [z80] _DABS0 region shifts absolutely addressed variable

[IvanDSM]

Hello all,

In a project using the Z80 port of SDCC I have a global absolutely addressed variable defined in my header file (render.h) as such:

uint8_t __at(0x11a) g_kicked = false;

In my source file (render.c) I check its value to stay in a loop until it is changed by an interrupt handler:

while (g_kicked == 0) {}

The lst file for this translation unit handles this properly, declaring g_kicked at the proper memory address and addressing _g_kicked+0 on the condition for my loop:

                                     30 ;--------------------------------------------------------
                                     31 ; absolute external ram data
                                     32 ;--------------------------------------------------------
                                     33     .area _DABS (ABS)
      00011B                         34     .org 0x011B
      00011B                         35 _g_kicked::
      00011B                         36     .ds 1
      00011D                         37     .org 0x011D

      [...]

                                           77 ;render.c:32: while (g_kicked == 0) {}
      000009                         78 00101$:
      000009 3Ar1Br01         [13]   79     ld  a, (_g_kicked+0)
      00000C B7               [ 4]   80     or  a, a
      00000D 28 FA            [12]   81     jr  Z, 00101$

However, the rel file indicates a different memory position for g_kicked:

A _DABS size 0 flags 8 addr 0
A _DABS0 size 1 flags 8 addr 11B
S _g_kicked Def00011B

Which is also seen in the sym file:

  4 _g_kicked                                                      00011B GR

Is this caused by a mistake of mine? If not, is there any way to avoid issues with this? It makes it complicated to properly define absolute addresses for variables.

I've attached my render.h, render.c and the resulting asm, lst, rel and sym files.

[IvanDSM]

Sorry, the information in this ticket is incorrect! I've ran a fresh build and found that the issue I'm having does not happen at the compilation stage but at the linking stage - the presence of the 0x11B address in the resulting lst/rel/sym files was the remnant of a test, and the fresh build has the correct 0x11A address in them, but the resulting binary still references 0x11B erroneously. Should I open a new ticket with the correct information about my issue?

[Maarten Brock]

You can continue here.