avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avr-gcc-list] avr-objcopy not copying custom section...


From: Boyapati, Anitha
Subject: RE: [avr-gcc-list] avr-objcopy not copying custom section...
Date: Sat, 26 Feb 2011 14:57:33 +0800


>-----Original Message-----
>From: address@hidden
>[mailto:address@hidden On
>Behalf Of darkschine
>Sent: Friday, February 25, 2011 4:24 PM
>To: address@hidden
>Subject: Re: [avr-gcc-list] avr-objcopy not copying custom section...
>
>
>I think the problem is your section flags. Try using "xa" instead of "x"
>
>

I think this is true.  Objcopy ignores any sections that are not allocatable 
when copying to ihex format. I think it makes sense as ihex is used more or 
less to represent the raw binary format.

Objcopy discards any debugging/symbol information while converting from ELF to 
raw binary format. Likewise if we try to copy to a section like '.stab' in ELF 
(.stab is not allocatable) to binary, the output is empty. The same behavior is 
seen in case of Elf->iHEX conversions.
 
HTH
Anitha

>
>Bill Westfield wrote:
>>
>> I am trying to add a version number to my program, to be located at an
>> absolute flash address.
>> But it looks like I can't get avr-objcopy to copy the section that I have
>> put this data in.
>>
>> I have in my .C file:
>>
>>      asm("  .section .version,\"x\"\n"
>>     "optboot_version:  .word " MAKEVER(OPTIBOOT_MAJVER, OPTIBOOT_MINVER)
>> "\n"
>>     "  .word 0x1234\n"
>>     "  .section .text\n");
>>
>> And then I link with (for example):
>>
>>       LDSECTIONS  = -Wl,--section-start=.text=0x3e00
>> -Wl,--section-start=.version=0x3ffc
>>
>> this seems to produce a correct .elf file:
>>
>> optiboot_diecimila.elf:     file format elf32-avr
>>>
>>> Sections:
>>> Idx Name          Size      VMA       LMA       File off  Algn
>>>   0 .text         000001d6  00003e00  00003e00  00000054  2**1
>>>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>>>   1 .version      00000004  00003ffc  00003ffc  0000022a  2**0
>>>                   CONTENTS, READONLY, CODE
>>>      :
>>>
>>> Contents of section .text:
>>>  3e00 112484b7 14be81ff d3d085e0 80938100  .$..............
>>>  3e10 82e08093 c00088e1 8093c100 86e08093  ................
>>>  3e20 c20080e1 8093c400 8ee0bcd0 259a86e0  ............%...
>>>  3e30 20e33cef 91e03093 85002093 840096bb   .<...0... .....
>>>  3e40 b09bfecf 1d9aa895 8150a9f7 99249394  .........P...$..
>>>  3e50 a5e0aa2e f1e1bf2e 9dd08134 21f481e0  ...........4!...
>>>  3e60 b2d083e0 1fc08234 11f484e1 03c08534  .......4.......4
>>>    :
>>> Contents of section .version:
>>>  3ffc 02043412                             ..4.
>>> Contents of section .debug_aranges:
>>>  0000 24000000 02000000 00000400 00000000  $...............
>>>
>>>
>> But objcopy seems to not include this section in output files, producing
>> an
>> empty hex file (data wise):
>>
>> BillW-MacOSX-2<8748> /sw/cross/bin/avr-objdump -sh optiboot_diecimila.elf
>> |
>>> less
>>> BillW-MacOSX-2<8748> /sw/cross/bin/avr-objcopy -j .version -O ihex
>>> optiboot_diecimila.elf foo.hex
>>> BillW-MacOSX-2<8749> more foo.hex
>>> :0400000300003E00BB
>>> :00000001FF
>>>
>>
>> Am I missing something obvious or is this some subtle bug to be tracked
>> down?
>>
>> Thanks
>> WestfW
>>
>> _______________________________________________
>> AVR-GCC-list mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>>
>>
>
>--
>View this message in context: http://old.nabble.com/avr-objcopy-not-
>copying-custom-section...-tp31011415p31011953.html
>Sent from the AVR - gcc mailing list archive at Nabble.com.
>
>
>_______________________________________________
>AVR-GCC-list mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/avr-gcc-list



reply via email to

[Prev in Thread] Current Thread [Next in Thread]