This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: nm: missing .rodata.*.str1.1 symbols
- From: Clément Péron <peron dot clem at gmail dot com>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: binutils at sourceware dot org
- Date: Thu, 23 Feb 2017 15:49:36 +0100
- Subject: Re: nm: missing .rodata.*.str1.1 symbols
- Authentication-results: sourceware.org; auth=none
- References: <CAJiuCcdAaBGuBnhSz4jSFTjg9kFV3i4=VQ5uzOT0TM73HEwq2g@mail.gmail.com> <ea2eed6a-30af-9dbf-815c-4e8b7adf3c90@redhat.com>
Hi Nick,
Many thanks, got it !
Is it possible to find the information that /tmp/cc9j6Kh2.o fill 8bytes in the
.rodata.str1.1 section somewhere else than in the map file ?
Cheers,
Clement
2017-02-23 15:28 GMT+01:00 Nick Clifton <nickc@redhat.com>:
> Hi Clément,
>
>> I compile a project but i don't see any .rodata.*.str1.1 symbols in nm.
>
> I think that there is a misunderstanding here. The .rodata.str1.1 names
> that you are seeing in the linker map file are not symbol names, they are
> section names.
>
>> But app.elf.map have 4 symbols and match with size :
>
> Breaking the output down, this part of the map file tells you that:
>
>> .rodata 0x00000000000007a0 0x27
>
> The .rodata section in the app.elf file starts at address 0x0..07a0
> and extends for 0x27 bytes.
>
>> *(.rodata .rodata.* .gnu.linkonce.r.*)
>
> This section was created by an entry in the linker script being used
> which contains the text indicated here.
>
>> .rodata.cst4 0x00000000000007a0 0x4
>> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/Scrt1.o
>
> The first entry in to the .rodata section comes from the .rodata.cst4
> section in the /usr/.../Scrt1.o input file. It occupies 4 bytes,
> starting at 0x0...07a0. Note - there is no *symbol* called .rodata.cst4.
>
>> 0x00000000000007a0 _IO_stdin_used
>
> A symbol definition has also been brought in from the /usr/.../Scrt1.o
> input file. The symbol is called _IO_stdin_used and it has the value
> 0x0...07a0.
>
>> .rodata.str1.1
>> 0x00000000000007a4 0xb /tmp/ccbpZVpr.o
>
> The next entry in the .rodata section of the app.elf file comes from the
> .rodata.str1.1 section in the /tmp/ccbpZVpr.o input file. This entry is
> 0xb bytes long and starts at address 0x0...074. Note - *no* symbols are
> brought in from this input section.
>
>> *fill* 0x00000000000007af 0x1
>
> The linker then pads the .rodata section to ensure 4-byte alignment.
>
>> .rodata 0x00000000000007b0 0x17 /tmp/ccbpZVpr.o
>> 0x00000000000007b0 str
>
> The next entry in the .rodata section is 0x17 bytes from /tmp/ccbpZVpr.o's
> .rodata section. This time a symbol is defined, named "str". That is TWO
> symbols so far...
>
>> .rodata.str1.1
>> 0x00000000000007c7 0x8 /tmp/cc9j6Kh2.o
>
> Finally 8 more bytes from /tmp/cc9j6Kh2.o's .rodata.str1.1 section are, in
> theory, added to the .rodata section. In practice these bytes are not added
> because they are identical to the ones brought in from the /tmp/ccbpZVpr.o
> input file. But this fact is not obvious in the map file.
>
> So - a total of TWO symbols are attached to the .rodata section in the app.elf
> file, exactly as displayed by nm.
>
> I hope that this explanation helps.
>
> Cheers
> Nick