https://sourceware.org/bugzilla/show_bug.cgi?id=1038
Takkelink <bryanmcsp at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bryanmcsp at gmail dot com --- Comment #6 from Takkelink <bryanmcsp at gmail dot com> --- https://www.southdublinroofers.ie avr-libc's C run-time startup code uses something like the following to initialize the stack: .weak __stack .set __stack, RAMEND ... ldi r28,lo8(__stack) #ifdef SPH ldi r29,hi8(__stack) out _SFR_IO_ADDR(SPH), r29 #endif out _SFR_IO_ADDR(SPL), r28 Here, RAMEND as a C preprocessor macro that depends on the actual processor type this code is being compiled for, and which evaluates to a 16-bit number by the time this code is being assembled. The idea behind that is that while the stack initially starts at top of RAM (growing downwards), the user can tune the actual stack location at link time by supplying a different value for the weak symbol __stack. However, as the value of __stack is already known to the assembler at that point, the assembler actually inserts the fixed value RAMEND instead of a reference to the weak symbol __stack, thereby entirely defeating the idea behind marking __stack as `weak' in the first place. By reordering the code, and placing the definition of __stack behind its use in the assembly code, the problem can be worked around, but I believe the assembler must not resolve symbols marked as `weak' in the first place but always leave that to the linker. -- You are receiving this mail because: You are on the CC list for the bug.