#2141 local variables & assembler


I have a situation where I suspect a rare error in SDCC. I successfully have passed numerical parameters to a function in registers, and I'm now trying to implement the passing of string address to a function (w/o parameters) via a register pair HL:

/* This defines work good for passing numerical parameters: */
#define __hash__ #
#define __id__(x) x
#define __ld_hl__(x) __asm ld hl,__id__(__hash__)x __endasm

/* Empty function, now we try to pass the string addr in pair HL into */
void WriteStr_FAST (void)

#define WriteStr(str) { \ char *strloc = str; __ld_hl__(_strloc); WriteStr_FAST(); }

int main (void)
WriteStr((char*)"Hello World");
return 0;

I've got this code and this message:

;XDevHello.c:20: WriteStr((char*)"Hello World");
ld hl,#_strloc
call _WriteStr_FAST
;XDevHello.c:21: return 0;
ld hl,#0x0000
.ascii "Hello World"
.db 0x00

?ASlink-Warning-Undefined Global '_strloc' referenced by module 'XDevHello'

For compiling I use this command line:

sdcc -mz80 --code-loc 26000 --data-loc 0xF800 --no-std-crt0 --opt-code-size --funsigned-char -I "." -I %lib% -L %lib%/z80 XDevHello.c

Let me suggest that SDCC finds the variable "strloc" as unused and removes it as unnecessary. And we just need to consider its using in a macro insertion.

If change the local variable to be the global, then no problems.

What do you think, does it looks like a bug in the SDCC? Thank you.

Oleg N. Cher
VEDAsoft Oberon Club


  • Maarten Brock

    Maarten Brock - 2013-12-19
    • status: open --> closed-rejected
    • assigned_to: Maarten Brock
    • Category: --> other
  • Maarten Brock

    Maarten Brock - 2013-12-19

    You could try to make strloc volatile, so it won't be removed.

    But I wouldn't consider this a bug. You're trying to make sdcc do things it doesn't support.

    I therefore close this bug report.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks