#3113 z80 (and related) assembler segfault

[Philipp Klaus Krause]

Trying to compile the following code

typedef struct {int x;} s;

s   _s;

void f(void)
{
__asm
    ld  b, #_s+6-_s
__endasm;
}

for a z80-related port, such as z80 or r2k, results in a segfault in the assembler.

[Sergey Belyashov]

Fault is caused by line asxxsrc/asout.c:525 because esp->e_base.e_sp == NULL. Function is called from asz80/z80mch.c:1126.

[zeynelsagcan]

I investigated issue #3113 further using SDCC r16998.

The original assembler access violation appears to have been addressed by the upstream change in [r16949]. However, testing revealed a separate issue involving valid complex symbol expressions and their relocation records.

For example:

.module complex_valid
.area _CODE
.globl _start

_start::
    ld hl, #_data_symbol-_start
    ret

.area _DATA
_data_symbol:
    .db 0x55

Without the patch, the assembler generates a synthetic expression symbol that is not correctly resolved by the linker. This results in an undefined-symbol warning and incorrect machine code.

The attached patch addresses the remaining expression-relocation issues by:

• Preserving synthetic expression symbol identities across assembler passes.
• Serializing complex expression definitions into REL files.
• Allowing the linker to parse and evaluate these definitions.
• Resolving dependencies between expression symbols.
• Detecting circular dependencies instead of silently generating incorrect machine code.
• Reporting malformed expression records as errors.

The patch was tested against the [r16998] source tree using the Z80 assembler and linker.

Validation results:

• Single complex expression: PASS
• Multiple independent complex expressions: PASS
• Dependent expression symbols: PASS
• Normal symbol resolution: PASS
• Undefined symbol detection: PASS
• Malformed expression rejection: PASS
• Circular dependency detection: PASS

The generated Intel HEX output was also verified against the expected Z80 machine code.

For the example above, the corrected output is:

:05000000210400C955B8
:00000001FF

I am attaching the combined patch for review.

This patch is intended to address the remaining complex-expression relocation and evaluation problems, rather than the original access violation already fixed in [r16949].

[Philipp Klaus Krause]

This is quite some changes in sdas. I'm reluctant to make such a big change deviating from upstream. How does this change compare to current upstream asxxxx 6.10? If the issues is fixed in upstream asxxxxm I'd prefer to fix it the same way on our side. If the bug still exists in upstream asxxxx, I suggest to submit the fix to upstream.

[Maarten Brock]

Note that the C example in this report is flawed. The assembly label _s needs an extra leading underscore. It should compile and assemble, but will fail to link due to an unresolved global symbol _s unless it is defined elsewhere.