1cxx etc is ram. and for some reason gdb is thinking that it is down in
ram which is probably where it ends up.
Not sure what is different in the elf file you are feeding into gdb. Which
gdb by the way.
it would help more if you include things like what gdb, what toolchain,
versions, etc.
this is kind of like throwing darts blindfolded and hoping we trip the mouse
trap just as the rat's tail is in the right position.
basically you should use and elf analyzer program (i don't know which one
off the top of my head. i'm sure binutils has something for looking at elf
output) and see what the differences in the two resultant files are.
Something is confusing gdb into doing something with .rodata that it
shouldn't be.
On Tue, Aug 30, 2011 at 1:20 AM, aliko <ali.tli...@gmail.com> wrote:
> I noticed strange addresses In output of gdb while loading binary (using
> load command).
> I'm using msp430f1611 chip. And the messages while loading are as follows:
> Loading section .rodata._ZL7xfConfD, size 0x58 lma 0x1c70
> Loading section .rodata._ZL10HART_confD, size 0x6a lma 0x1cc8
> Loading section .rodata.small_font, size 0xe lma 0x1d32
> Loading section .rodata._ZL16font_small_table, size 0x3a8 lma 0x1d40
> Loading section .rodata._ZL24font_small_mapping_table, size 0x100 lma
> 0x20e8
> Loading section .rodata._ZL23font_small_offset_table, size 0x138 lma 0x21e8
> Loading section .rodata._ZL23font_small_detail_table, size 0x138 lma 0x2320
> Loading section .rodata.big_font, size 0xe lma 0x2458
> Loading section .rodata._ZL19font_big_char_table, size 0x128 lma 0x2466
> Loading section .rodata._ZL22font_big_mapping_table, size 0x100 lma 0x258e
> Loading section .rodata._ZL20font_big_width_table, size 0xd lma 0x268e
> Loading section .rodata._ZL21font_big_offset_table, size 0x1a lma 0x269c
> Loading section .rodata._ZL21font_big_detail_table, size 0x1a lma 0x26b6
> Loading section .rodata._ZL12adc_channels, size 0x5 lma 0x26d0
> Loading section .rodata._ZL11const_types, size 0x40 lma 0x26d5
> Loading section .rodata._ZL8bits_cnt, size 0x10 lma 0x2715
> Loading section .rodata._ZL8bits_msk, size 0x5 lma 0x2725
> Loading section .text, size 0x784e lma 0x4000
> Loading section .data, size 0x14 lma 0xb84e
> Loading section .vectors, size 0x20 lma 0xffe0
> Start address 0x4000, load size 33595
>
> As I understand lma is the addresses where data goes. But there should
> not be addresses like 0x1c70, 0x1cc8 and so on. The code memory of this
> chip is starting at 0x4000! But data goes to RAM and after the first
> reboot it did not working as expected.
>
> But if I compile and load with old mspgcc4 the output is normal:
>
> 0x00004000 in _reset_vector__ ()
> Erasing target flash - all... Erased OK
> Loading section .text, size 0x7d38 lma 0x4000
> Loading section .data, size 0x14 lma 0xbd38
> Loading section .rodata._ZL7xfConfD, size 0x58 lma 0xbd4c
> Loading section .rodata._ZL10HART_confD, size 0x6a lma 0xbda4
> Loading section .rodata.small_font, size 0xe lma 0xbe0e
> Loading section .rodata._ZL16font_small_table, size 0x3a8 lma 0xbe1c
> Loading section .rodata._ZL24font_small_mapping_table, size 0x100 lma
> 0xc1c4
> Loading section .rodata._ZL23font_small_offset_table, size 0x138 lma 0xc2c4
> Loading section .rodata._ZL23font_small_detail_table, size 0x138 lma 0xc3fc
> Loading section .rodata.big_font, size 0xe lma 0xc534
> Loading section .rodata._ZL19font_big_char_table, size 0x128 lma 0xc542
> Loading section .rodata._ZL22font_big_mapping_table, size 0x100 lma 0xc66a
> Loading section .rodata._ZL20font_big_width_table, size 0xd lma 0xc76a
> Loading section .rodata._ZL21font_big_offset_table, size 0x1a lma 0xc778
> Loading section .rodata._ZL21font_big_detail_table, size 0x1a lma 0xc792
> Loading section .rodata._ZL12adc_channels, size 0x5 lma 0xc7ac
> Loading section .rodata._ZL11const_types, size 0x40 lma 0xc7b1
> Loading section .rodata._ZL8bits_cnt, size 0x10 lma 0xc7f1
> Loading section .rodata._ZL8bits_msk, size 0x5 lma 0xc801
> Loading section .vectors, size 0x20 lma 0xffe0
>
> Notice the addreses are now within the code memory and the program works
> good.
>
> Could anyone tell me please how can I fix wrong data placing in new
> versions of compiller?
>
> Thanks in advance!
>
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
