#2772 sdasstm8 seg faults on null pointer deref

[David Gould]

Using the 3.7.0 source release or the binary snapshot from 20180721 the sdasstm8 assembler fails with a segv. I have attached a core file and the asm (generated by sdcc). The platform is 64 bit ubuntu 18.04. I simplified the command to:

sdasstm8 -go main.asm

Core was generated by `/home/dg/Electronics/STM8/tools/sdcc/bin/sdasstm8 -go main.asm'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  outrw (esp=0x7ffc8e16f540, r=<optimized out>) at ../asxxsrc/asout.c:648
648                                                 n = esp->e_base.e_sp->s_ref;
(gdb) l
643                         if (oflag) {
644                                 if (!is_sdas() || !is_sdas_target_8051_like()) {
645                                         outchk(2, 4);
646                                         out_txb(2, esp->e_addr);
647                                         if (esp->e_flag) {
648                                                 n = esp->e_base.e_sp->s_ref;
649                                                 r |= R_SYM;
650                                         } else {
651                                                 n = esp->e_base.e_ap->a_ref;
652                                         }
(gdb) bt
#0  outrw (esp=0x7ffc8e16f540, r=<optimized out>) at ../asxxsrc/asout.c:648
#1  0x000055e814e05305 in asmbl () at ../asxxsrc/asmain.c:1567
#2  0x000055e814dfdfa2 in main (argc=3, argv=<optimized out>) at ../asxxsrc/asmain.c:530

[David Gould]

Please let me know if there is any way I can help resolve this.

[Erik Petrich]

While the assembler shouldn't segfault, it looks like the root cause is that the compiler is generating a malformed frame descriptor entry in the DWARF debugging data. In your main.asm file are these lines:

Ldebug_CIE0_end:
          .dw     0,12
          .dw     0,(Ldebug_CIE0_start-4)
          .dw     0,0     ;initial loc
          .dw     0,(null)-(null)

The (null)-(null) should actually refer to the debugging symbols that define the range of source lines that this frame descriptor should be used for, but the compiler did not have the debugging symbols when this was generated. I suspect that the compiler should not have attempted to generate this frame descriptor entry at all. The assembler seems to be having a problem figuring out how to generate a relocation record for the difference of two unknown symbols (since "null" is undefined, it is assumed to be an externally defined symbol)

A short-term work-around would be to not generate debugging information.

[David Gould]

There were undefined symbols in there because the makefile missed a couple sources.I fixed that and used your suggestion and got the project to build and link but without debug information. I had hoped resolving the undefined symbols might have let debug info work too, but no such luck. With debug info on it still segvs. I have not verified that it is the same though. Anyway, I'm going to try to simplify the reproduction for you.

[David Gould]

I have simplifed the reproduction of this bug. If you download the three files and run ./test.sh with sdcc in your path it will make a core file for you. Let me know if I can help somehow. In main.c you can comment out the define of BUG and it will build successfully. It appears the problem is with statics declared and initialized in functions.

May I also suggest you not strip the binaries by default. It makes debugging much less convenient and disk space is quite ample these days.

[David Gould]

This bug appears to be related to bug [#2741].