This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/82624] New: [msp430] Target must allow for NULL pointer dereferences


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82624

            Bug ID: 82624
           Summary: [msp430] Target must allow for NULL pointer
                    dereferences
           Product: gcc
           Version: 7.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: oarias at knights dot ucf.edu
  Target Milestone: ---

Created attachment 42406
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42406&action=edit
Disable -fdelete-null-pointer-checks in the msp430-elf target.

Greetings,

I filed a similar bug report to this one a few months ago [1]. I have come back
now more informed and with a fix (although for a different target). When
compiling the following code with -O2 or higher, the compiler generates a call
to abort.

void test(void) {
    volatile unsigned char* p = (volatile unsigned char*)0;
    *p = 0;
}

$ msp430-elf-gcc -O2 -S -mcpu=msp430 test.c

test:
        MOV.B   #0, &0
        CALL    #abort

(I believe gcc8 now generates an error for this instead of silently issuing bad
code, which is a lot saner.)

This is due to the activation of the -fdelete-null-pointer-checks option.
However, in MSP430, the memory area from 0x0000 to 0x000f is reserved for the
special function registers. These can be legitimately accessed by the software
during a read or write operation. For example, in the MSP430G2553, address 0
points to register IE1 (Interrupt Enable Register 1). Without access to this
register in that particular microcontroller, we are unable to enable interrupts
for the flash memory controller, watchdog timer, and USART module.

The reason we have yet to run into this particular issue is because the way TI
defines these symbols in the linker script that they distribute for the
msp430-elf toolchain:

PROVIDE(IE1                = 0x0000);

However, if using a definition from a header file which explicitly declares a
register as a pointer to address 0, code will fail to compile properly.

The attached patch disables this optimization for the msp430-elf target. I
_think_ it also updated all relevant bits of the documentation and the test
suite. If the latter is wrong, let me know what needs to be changed and I can
resubmit it. Thank you.

Cheers,
Orlando.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81720

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]