#3030 mcs51 SIGSEGV on array after #include <stdlib.h>

[Gabriel Ravier]

#include <stdlib.h>
wchar_t array[] = L"";

Compiling this with sdcc test.c results in Caught signal 11: SIGSEGV. Tested with commit 11647.

[Philipp Klaus Krause]

This crashes in the mcs51 register allocator.

I've tried mcs51, z80, pdk14, stm8, hc08, ds390. Only mcs51 crashed for me, the other ports apparently generate good code.

[Maarten Brock]

This passes for --model-medium / --modem-large / --model-huge and also for --model-small --stack-auto. Only --model-small fails for which wchar is also not tested in regression test wchar.c due to memory restrictions.

[Philipp Klaus Krause]

Actually, this is not about strings at all. The following fails the same way:

#include <stdlib.h>

int test[] = {1, 2};

[Philipp Klaus Krause]

Looks like another of those issues where too much iCode is generated for the initialization of a global, and codegen assumes it is inside a function when it is not.

[Maarten Brock]

What do you mean by too much iCode?

Codegen should not assume to be inside a function. Initialization of global/static __data variables does not happen inside a function. Instead code is generated for that in the GSINIT section.

[Philipp Klaus Krause]

Typically, we see issues if the iCode gets so complex that temporaries cannot be allocated to registers. Apparently codegen (and some other stuff) assumes that we are in a function at least as soon as some variables are spilt. And it looks like this is what happens here, too.

P.S.:

Program received signal SIGSEGV, Segmentation fault.
0x00005555555ec038 in canOverlayLocals (ebbs=0x555555d0a680, count=1) at SDCCmem.c:1285
1285      if (IFFUNC_ISOVERLAY(currFunc->type)) return TRUE;

[Philipp Klaus Krause]

While that explains the symptoms (and the place where the crash happens - since [r14007], there is also an assertion for this), it doesn't explain why it only happens, if we have a header include followed by an initialized array, while the include alone and the array alone are fine. And even the include followed by the array is fine if they are followed by a function definition (a function declaration by itself won't help).

P.S.: From the include, we just needed an inline function with at least one parameter. The following code is by itself sufficient to trigger the bug:

inline void free_sized(int i)
{
}

int test[] = {1, 2};

Apparently, after the inline function definition, overlay->syms is nonempty, which results in this bug.

[Philipp Klaus Krause]

In SDCCmem.c, we have this comment:

/* again note that we have put it into the overlay segment
     will remove and put into the 'data' segment if required after
     overlay  analysis has been done */

It looks like for inline functions, we never remove the thing from the overlay segment, so the overlay segment never gets cleaned up, resulting in this bug.

[Philipp Klaus Krause]

Fixed in [r14008].