Thanks for the quick response, Peter.
I did start digging into the mystery with more objdumps. However, the
problem turned out to be a simple case of one file declaring a variable as
uint8_t and another extern'ing it with uint16_t. The error message was a
little scary, but the linker was actually doing the right thing. :-)
On Mon, Feb 25, 2013 at 5:05 AM, Peter Bigot <big...@acm.org> wrote:
> The linker error means there's either a word memory access or a
> PC-relative jump where the relocation would store an odd address. You need
> to figure out what the relocation is, and why the data it references isn't
> aligned properly.
>
> Use "msp430-objdump -dr file.o" to dump the content of the object file
> along with relocations (if the relocation is in the data section instead of
> the code section you may need additional flags). You can see something
> like this:
>
> 2a: b0 12 00 00 call #0x0000
> 2c: R_MSP430_16_BYTE printf
>
> which tells you where the offset is relative to the start of the function,
> and what the name of the object whose actual address is to be written in.
> Then you can look in the table to see what address that object (printf
> above) is at.
>
> That there are multiple *.rodata.fn sections is an artifact of the
> different things that can be put into an rodata section. Switch jump
> tables may not have a region qualifier for technical reasons I don't
> remember offhand.
>
> Peter
>
> On Sun, Feb 24, 2013 at 8:27 PM, Andy Turk <andyt...@gmail.com> wrote:
>
>> I'm using the 20-bit development version of mspgcc and am blocked by a
>> linker error: "dangerous relocation: unaligned address":
>>
>> make test.elf
>> msp430-gcc -I/usr/local/msp430/include -std=c99 -Wall -Os -g
>> -mmcu=msp430f5528 -mmemory-model=large -ffunction-sections -fdata-sections
>> -Ibuild -c file.c -o build/obj/file.o
>> msp430-gcc -mmcu=msp430f5528 -mmemory-model=large -Wl,-gc-sections <… many
>> .o files…> -o build/test.elf
>> build/obj/file.o: In function `sm_packet_handler':
>> /Users/andy/code/.../file.c:1569:(.any.text.sm_packet_handler+0x4ac):
>> dangerous relocation: unaligned address
>> collect2: error: ld returned 1 exit status
>> make: *** [test.elf] Error 1
>>
>> I have no clue as to what's going on, or what I can do to fix it. The
>> function that appears to be generating the error is fairly large with a
>> number of nested switch statements. But I'm not sure if sm_packet_handler
>> is at fault, or whether a symbol it references is causing the problem.
>>
>> One thing I noticed in dumping the .o file is that sm_packet_handler is
>> using two different ".rodata" sections:
>>
>> $ msp430-objdump -h build/obj/file.o | grep sm_packet_handler
>> 17 .any.rodata.sm_packet_handler 00000011 00000000 00000000 0000096c
>> 2**0
>> 18 .any.text.sm_packet_handler 00000d94 00000000 00000000 0000097e
>> 2**1
>> 19 .rodata.sm_packet_handler 00000154 00000000 00000000 00001714 2**2
>>
>> Is that relevant at all? Has anyone else run into this error message?
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>> _______________________________________________
>> Mspgcc-users mailing list
>> Mspgcc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>>
>>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
