This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/82624] New: [msp430] Target must allow for NULL pointer dereferences
- From: "oarias at knights dot ucf.edu" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 19 Oct 2017 18:09:56 +0000
- Subject: [Bug target/82624] New: [msp430] Target must allow for NULL pointer dereferences
- Auto-submitted: auto-generated
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