This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: nm: missing .rodata.*.str1.1 symbols


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]