avr-libc-dev
[Top][All Lists]
Advanced

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

Re: [avr-libc-dev] [Patch] Include a device info note section in gcrt1.S


From: Senthil Kumar Selvaraj
Subject: Re: [avr-libc-dev] [Patch] Include a device info note section in gcrt1.S
Date: Tue, 14 Oct 2014 16:29:19 +0530
User-agent: Mutt/1.5.23 (2014-03-12)

On Sat, Oct 11, 2014 at 10:35:22AM +0200, Joerg Wunsch wrote:
> I finally had a chance to test all this.
> 
> For reference, here's the result for an ATmega1281:
> 
> % avr-objdump -h -j .note.gnu.avr.deviceinfo -s 
> avr/lib/avr5/atmega1281/crtm1281.o
> 
> avr/lib/avr5/atmega1281/crtm1281.o:     file format elf32-avr
> 
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>  11 .note.gnu.avr.deviceinfo 00000034  00000000  00000000  0000181c  2**2
>                   CONTENTS, READONLY
> Contents of section .note.gnu.avr.deviceinfo:
>  0000 04000000 23000000 01000000 41565200  ....#.......AVR.
>  0010 00000000 00000200 00020000 00200000  ............. ..
>  0020 00000000 00100000 08000000 01000000  ................
>  0030 00000000                             ....            
> 
> 
> As Senthil Kumar Selvaraj wrote:
> 
> > How does the below patch look? Once you guys find it ok, I'll follow it
> > up with a documentation patch. Note that the part above the
> > L__desc_start label (and the .balign directive at the end) are there as
> > per the ELF spec for a note section.
> 
> OK, if that's required, we have to stick with that.
> 
> Wouldn't the note name string also possibly need padding
> for alignment behind it?  (In the case of the "AVR\0",
> it only incidentally aligns the following .long values
> to a long boundary.)

Yes, I figured it's only going to be "AVR\0", so I skipped the align
directive. I'll add it.
> 
> For the documentation, please include a C struct definition
> as explanation:
> 
> #define __NOTE_NAME_LEN 4
> struct __note_gnu_avr_deviceinfo
> {
>     struct
>     {
>         uint32_t note_name_len;          /* = __NOTE_NAME_LEN */
>         uint32_t desc_len;
>         char note_name[__NOTE_NAME_LEN]; /* = "AVR\0" */
>     }
>     elfinfo_hdr;
>     struct
>     {
>         uint32_t flash_start;
>         uint32_t flash_size;
>         uint32_t sram_start;
>         uint32_t sram_size;
>         uint32_t eeprom_start;
>         uint32_t eeprom_size;
>         uint32_t offset_table[2];  /* index 0: ... */
>         // ???
>     }
>     avr_desc;
> };

Ok, will do.
> 
> > +.L__stroffsettab_end:
> > +    /* String table for storing arbitrary strings.
> > +    Offsets are stored in the string offset table above */
> > +.L__strtab_start:
> > +    .byte 0
> > +.L__device_name_start:
> > +    .asciz DEVICE_NAME
> > +.L__device_name_end:
> > +    .byte 0
> > +.L__strtab_end:
> 
> I don't quite understand the purpose of the two ".byte 0" definitions.

I used the standard ELF string table convention - the first and last
bytes are null. From http://man7.org/linux/man-pages/man5/elf.5.html,

"String table sections hold null-terminated character sequences,
commonly called strings.  The object file uses these strings to
represent symbol and section names.  One references a string as an
index into the string table section.  The first byte, which is index
zero, is defined to hold a null byte ('\0').  Similarly, a string
table's last byte is defined to hold a null byte, ensuring null
termination for all strings."

There's no need to follow that convention though - the descriptor's
layout/interpretation can be arbitrary. If you think it is redundant,
I'll drop it.

I'll send a new patch with all the changes.

Regards
Senthil



reply via email to

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