Greetings, I ran into a rather puzzling issue with ld.bfd for the MSP430 target with binutils 2.40, gcc 12.2, and newlib 4.2.0.20211231. Consider the following program: #include void main(void) { WDTCTL = WDTPW | WDTHOLD; P3DIR = BIT4; P3OUT &= ~BIT4; while(1) { __delay_cycles(2500000); P3OUT ^= BIT4; } } Build and link the program as: $ msp430-elf-gcc -mmcu=msp430fr5739 -Wall -Wno-main -Werror \ -ffunction-sections -fdata-sections -Os -c -o gpio.o gpio.c $ msp430-elf-gcc -mmcu=msp430fr5739 -Wl,--gc-sections -\ o binary.elf gpio.o The linker script used is from the TI support files found at [1,2]. I am attaching it here for convenience. When linking, I get the following warning: /usr/bin/msp430-elf-ld: warning: binary.elf has a LOAD segment with RWX permissions and indeed, when examining the binary in question (also attached), I see $ msp430-elf-readelf -l binary.elf Elf file type is EXEC (Executable file) Entry point 0xc208 There are 4 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x0000c14c 0x0000c14c 0x0016e 0x0016e RWE 0x4 LOAD 0x000000 0x00001c00 0x0000c2ba 0x00000 0x00010 RW 0x4 LOAD 0x000000 0x00001c10 0x0000c2ba 0x00000 0x00004 RW 0x4 LOAD 0x00016e 0x0000fffe 0x0000fffe 0x00002 0x00002 R 0x4 Well, indeed there is something that gets placed at 0xc14c that is read write and executable. However, the MSP430FR5739 has nothing on that memory region! In fact, looking at the linker scripts reveals nothing that should be placed there, unless I am missing something of course. For that matter, when running size on the binary, I get: $ msp430-elf-size binary.elf text data bss dec hex filename 180 8 20 208 d0 binary.elf Which is also interesting. When looking into readelf, I see: $ msp430-elf-readelf -S binary.elf There are 20 section headers, starting at offset 0xb08: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] __reset_vector PROGBITS 0000fffe 000182 000002 00 A 0 0 1 [ 2] .rodata PROGBITS 0000c200 000184 000000 00 WA 0 0 1 [ 3] .rodata2 INIT_ARRAY 0000c200 0000b4 000008 04 WA 0 0 4 [ 4] .persistent PROGBITS 0000c208 000184 000000 00 WA 0 0 1 [ 5] .text PROGBITS 0000c208 0000bc 0000c4 00 AX 0 0 2 [ 6] .data PROGBITS 00001c00 000184 000000 00 WA 0 0 1 [ 7] .bss NOBITS 00001c00 000180 000010 00 WA 0 0 2 [ 8] .noinit NOBITS 00001c10 000000 000000 00 WA 0 0 1 [ 9] .heap NOBITS 00001c10 000180 000004 00 WA 0 0 1 [10] .MSP430.attr[...] MSP430_ATTRIBUT 00000000 000184 000017 00 0 0 1 [...snip...] Which reveals a 0 length .data section and a 16 byte .bss section. Looking into symbols to see what got placed where, I see: $ msp430-elf-nm -n binary.elf [relevant parts shown only] 00001c00 D _edata 00001c10 B _end 00001c10 B end 00001c10 B __heap_start__ 00001c14 B __heap_end__ 00001c14 B __HeapLimit 00002000 N __stack 0000c208 T __crt0_start 0000c208 T _start [...snip...] which makes it look like something went into .bss after all. I am guessing it is because of all the ALIGN() stuff in the ldscript? In any case, I have no idea where extraneous segment is coming from. Nothing on the binary indicates that it should exist, and there is nothing in the memory map of the MSP430 in question in that area. I did notice that a patch was submitted to treat the cris*-elf backend in a special way by defaulting to --no-warn-rwx-segment which I guess could be done as well for the MSP430. There is no MMU on the MSP430 (there is an MPU on the FR5739 which I am using for the example above, but it must be manually configured by the software running on the platform). This could also be applied to the MSP430 but it feels like a workaround that may be hiding a different problem. Could someone shed some light as to what is going on here? Thank you for your time and efforts. Cheers, Orlando. [1] https://www.ti.com/tool/MSP430-GCC-OPENSOURCE#downloads [2] https://dr-download.ti.com/software-development/ide-configuration-compiler-or-debugger/MD-LlCjWuAbzH/9.3.1.2/msp430-gcc-support-files-1.212.zip [3] https://sourceware.org/pipermail/binutils/2022-May/121065.html