This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I'm porting code written from mspgcc 4.6.3 into a CCS 6.0.1 project with TI mspgcc 4.9.1.
MSP430FR59xx is the MCU type.
When linking the symbol _end (as I can read from the code it is the start of RAM + sizeof(data) + sizeof(bss) ) is undefined:
./cpu/msp430-common/msp430-main.o:(.data+0x0): undefined reference to `_end' collect2.exe: error: ld returned 1 exit status
What symbol name instead of _end I have to use for gcc 4.9.1?
below the code snippet:
extern int _end; /* Not in sys/unistd.h */ static char *cur_break = (char *) &_end; #define asmv(arg) __asm__ __volatile__(arg) #define STACK_EXTRA 32 /* * Allocate memory from the heap. Check that we don't collide with the * stack right now (some other routine might later). A watchdog might * be used to check if cur_break and the stack pointer meet during * runtime. */ void *sbrk(int incr) { char *stack_pointer; asmv("mov r1, %0" : "=r"(stack_pointer)); stack_pointer -= STACK_EXTRA; if (incr > (stack_pointer - cur_break)) { return (void *) - 1; /* ENOMEM */ } void *old_break = cur_break; cur_break += incr; /* * If the stack was never here then [old_break .. cur_break] should * be filled with zeros. */ return old_break; }
Greetings
Attilio
I cannot find where this detail is explained in the documentation. I think the symbol name is "end". That is because I looked at some executables with the names utility. The command could look like ...
% msp430-elf-nm -n executable_file | less
Search for "end". I expect you will only find "end" and never "_end". The -n option sorts the output by address, so you can see, based on the names of nearby symbols, whether the address makes sense for your system.
Thanks and regards,
-George
Thanks George!
It make sense and seems reasonable that the end symbol is the right address, but ...
for confirmation I made this simple case:
#include <msp430.h> /* * main.c */ int main(void) { WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer return 0; }
then:
$ msp430-elf-size.exe e2e-post.out text data bss dec hex filename 582 146 18 746 2ea e2e-post.out
So I expect end = 0x1c00 + 146 + 18 = 0x1ca4
but instead
$ msp430-elf-nm.exe -n e2e-post.out 00000012 A __bsssize 0000007e A __romdatacopysize 00001c00 D __datastart 00001c00 d __JCR_END__ 00001c00 d __JCR_LIST__ 00001c02 D __dso_handle 00001c04 D _impure_ptr 00001c06 d impure_data 00001c7e B __bssstart 00001c7e D _edata 00001c7e b completed.2761 00001c80 b dtor_idx.2763 00001c82 b object.2776 00001c90 N end
from nm outuput end is 0x1c90, not 0x1ca4.
What I miss?
regards
Attilio
That's because "end" marks the end of the .bss section. 0x1c7e + 0x12 = 0x1c90.
Thanks and regards,
-George
The "data" column from the "size" program apparently includes more than what you're considering data. I played around with some GCC executables, and it seems that (_edata-__datastart) is the size of the .data section only; there are other data sections.
Try using the "-A" argument to msp430-elf-size.exe for a more detailed section listing.
Looking at the output of "nm", we see that (end-__bssstart) is 18, as expected, and (_edata-__datastart) is 126. This leaves 20 extra bytes unaccounted for in the "data" column of the "size" program. Possibly const data?
It looks like the "data" column is the total size of all writable data sections including .data, but excepting .bss.
Ok, data section reported by msp430-elf-size is the sum of .data (RAM) and .rodata (ROM) data:
$ msp430-elf-size.exe -A e2e-post.out e2e-post.out : section size addr __reset_vector 2 65534 .rodata 20 17408 .text 580 17428 .data 126 7168 .bss 18 7294 .MP430.attributes 322 0 .comment 123 0 .debug_aranges 400 0 .debug_info 6233 0 .debug_abbrev 1149 0 .debug_line 2370 0 .debug_frame 156 0 .debug_str 1823 0 .debug_loc 563 0 .debug_ranges 120 0 .debug_line.text.__errno 22 0 .debug_line.text.memmove 64 0 .debug_line.text.memset 34 0 Total 14125
Thanks again!
Attilio