I had played with this a little, and discovered (as you did) the necessity
of including the -mmcu option for the linker (without it, certain constants
such as the stack address get a default value that's wrong unless you're
targeting an MSP430F110 or something similar). I got to the point where I
could duplicate the problem by attempting to link an executable with the
combined object file:
CFLAGS="-Wall -Os -mmcu=cc430x5137"
msp430-gcc ${CFLAGS} -c m.c
msp430-gcc ${CFLAGS} -c add2.c
msp430-gcc ${CFLAGS} -c putchar.c
msp430-ld -mcc430x5137 -r -o add.so m.o add2.o
msp430-gcc ${CFLAGS} -o a.out putchar.o add.so
Would you please file a tracker bug report on the mspgcc project? I'll see
what I can do to make the above work with mspgcc4, though can't promise that
the result will satisfy Contiki's symbol resolution needs.
Peter
On Wed, Dec 22, 2010 at 10:47 PM, Martin <deve...@gmail.com> wrote:
> Chris Liechti <cliechti <at> gmx.net> writes:
>
> >
> >
> > Am 21.12.2010 14:09, schrieb devebox:
> > >> msp430-gcc -Wall -Os -c m.c -o m.o
> > >> msp430-gcc -Wall -Os -c add2.c -o add2.o
> > >> msp430-ld -r --unresolved-symbols=ignore-in-object-files --strip-all
> > > -o m.cm m.o add2.o
> >
> > note that the C compiler uses things from the libraries libc and libgcc.
> > when you call "ld" these are not added automatically. the symbols are
> > missing (zero) in your readelf outout because you don't link the
> libraries.
> >
> > it's recommended to use also "gcc" as command for the linking. it
> > automatically adds the required libs. thus, just replace "msp430-ld"
> > with "msp430-gcc".
> >
> > chris
> >
> >
> ------------------------------------------------------------------------------
> > Forrester recently released a report on the Return on Investment (ROI) of
> > Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
> > within 7 months. Over 3 million businesses have gone Google with Google
> Apps:
> > an online email calendar, and document program that's accessible from
> your
> > browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
> >
>
>
> Hi Chris,
>
> Thanks much for the tip. I intentionally wanted to leave out the standard
> libraries. I am compiling a loadable module for the contiki OS. The OS core
> contains definitions of lib symbols and it provides a dynamic linker/loader
> that is suppose to hook up the undefined symbols in my module with the
> definitions in core. I used the "--unresolved-symbol" option for this
> reason.
>
> To check if missing lib is indeed the culprit, I replaced msp430-ld with
> msp430-gcc, but also added -Wl, and -mmcu options to pass options to the
> linker,
> and to avoid a complain about "the region .text is full".
>
> > make m.cm
> msp430-gcc -mmcu=msp430x1611 -Wall -Os -c m.c -o m.o
> msp430-gcc -mmcu=msp430x1611 -Wall -Os -c add2.c -o add2.o
> msp430-gcc -mmcu=msp430x1611 -Wl,-r \
> -Wl,--unresolved-symbols=ignore-in-object-files \
> -Wl,--strip-all -o m.cm m.o add2.o
>
> > readelf -a m.cm
> Relocation section '.rela.text' at offset 0x9a8 contains 63 entries:
> Offset Info Type Sym.Value Sym. Name + Addend
> 00000008 00000d05 R_MSP430_16_BYTE 00000752 _etext + 0
> 0000000c 00002a05 R_MSP430_16_BYTE 00000000 __data_start + 0
> 00000010 00002605 R_MSP430_16_BYTE 00000000 _edata + 0
> 00000022 00001e05 R_MSP430_16_BYTE 00000000 __bss_start + 0
> 00000026 00001305 R_MSP430_16_BYTE 00000000 __bss_end + 0
> 00000038 00002103 R_MSP430_16 00000078 main + 0
> 0000003c 00001a03 R_MSP430_16 0000003e _unexpected_ + 0
> 0000007a 00002505 R_MSP430_16_BYTE 00003900 __stack + 0
> 00000082 00000105 R_MSP430_16_BYTE 00000000 .text + 0 (A)
> 00000086 00000c05 R_MSP430_16_BYTE 000000ca printf + 0
> 0000008e 00002705 R_MSP430_16_BYTE 000000b2 add2 + 0
> 00000094 00000105 R_MSP430_16_BYTE 00000000 .text + 19 (B)
> 00000098 00000c05 R_MSP430_16_BYTE 000000ca printf + 0
> 000000a0 00000e03 R_MSP430_16 00000724 __stop_progExec__ + 0
> 000000ba 00000105 R_MSP430_16_BYTE 00000000 .text + 0 (C)
> 000000be 00000c05 R_MSP430_16_BYTE 000000ca printf + 0
> 000000d4 00000b05 R_MSP430_16_BYTE 00000000 putchar + 0
> 000000d8 00001c05 R_MSP430_16_BYTE 00000140 vuprintf + 0
> 000000f4 00000403 R_MSP430_16 00000000 .bss + 0
> 000000fc 00000303 R_MSP430_16 00000000 .data + 0
> 00000122 00000403 R_MSP430_16 00000000 .bss + 0
> (truncated)
>
>
> However, I still get the zero addend at (C) which is the argument to
> the printf statement in add2.c.
>
> I wondered if this problem is specific to msp430, so I tried to compile
> that some source files for avr:
>
> > make m.cm
> avr-gcc -mmcu=atmega1284p -Wall -O2 -c m.c -o m.o
> avr-gcc -mmcu=atmega1284p -Wall -O2 -c add2.c -o add2.o
> avr-gcc -mmcu=atmega1284p -O2 -Wl,-r \
> -Wl,--unresolved-symbols=ignore-in-object-files \
> -Wl,--strip-all -o m.cm m.o add2.o
>
> > readelf -r m.cm
> (trancrated)
> 000000a6 00000203 R_AVR_13_PCREL 00000000 .text + ac
> 000000ac 00002106 R_AVR_LO8_LDI 00000000 __data_end + 0
> 000000b0 00000202 R_AVR_7_PCREL 00000000 .text + a8
> 000000c2 00002712 R_AVR_CALL 000000ce main + 0
> 000000c6 00003312 R_AVR_CALL 000006c2 exit + 0
> 000000ce 00000203 R_AVR_13_PCREL 00000000 .text + d0
> 000000d0 00000203 R_AVR_13_PCREL 00000000 .text + d2
> 000000d2 00000106 R_AVR_LO8_LDI 00000000 .data + 0 (A)
> 000000d4 00000107 R_AVR_HI8_LDI 00000000 .data + 0
> 000000e6 00000712 R_AVR_CALL 00000152 printf + 0
> 000000f6 00003412 R_AVR_CALL 00000120 add2 + 0
> 000000fa 00000203 R_AVR_13_PCREL 00000000 .text + fc
> 000000fc 00000203 R_AVR_13_PCREL 00000000 .text + fe
> 000000fe 00000106 R_AVR_LO8_LDI 00000000 .data + 19 (B)
> 00000100 00000107 R_AVR_HI8_LDI 00000000 .data + 19
> 0000010e 00000712 R_AVR_CALL 00000152 printf + 0
> 00000126 00000203 R_AVR_13_PCREL 00000000 .text + 128
> 00000128 00000203 R_AVR_13_PCREL 00000000 .text + 12a
> 0000012a 00000106 R_AVR_LO8_LDI 00000000 .data + 38 (C)
> 0000012c 00000107 R_AVR_HI8_LDI 00000000 .data + 38
> 0000013a 00000712 R_AVR_CALL 00000152 printf + 0
> 000006c4 00000203 R_AVR_13_PCREL 00000000 .text + 6c4
> 000000b2 00001307 R_AVR_HI8_LDI 00000000 __bss_end + 0
> 000000b4 00002606 R_AVR_LO8_LDI 00000000 __bss_start + 0
> 000000b6 00002607 R_AVR_HI8_LDI 00000000 __bss_start + 0
> 000000b8 00000203 R_AVR_13_PCREL 00000000 .text + bc
> 000000bc 00001306 R_AVR_LO8_LDI 00000000 __bss_end + 0
> (trancated)
>
> In this case avr-gcc decided to put the printf arguments into the .data
> section, but otherwise the addends are correct for all three printf
> statements.
>
> I use gcc version 3.2.3, but I also tried mspgcc4 (with gcc version 4.4.3)
> and got the same results.
>
> Please kindly let me know if I'm missing something. Thanks a lot.
>
>
> Martin
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment,
> and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
