local symbols problem for RTL

[Peng Fan]

2013/5/31 Chris Johns <chrisj at rtems.org>

> Peng Fan wrote:
>
>> hi,
>> Now I have a idea about how to include local symbols in the RAP file,
>> and try to not increase the size of the RAP file.
>>
>> 1. About the relocations.
>> The current layout for the relocations  is:
>> | header | reloc entries|
>> the first bit of header indicates whether it is rela or not. the
>> remaining 30 bits indicates the number of reloc entries.
>>
>> But now I want to include elf object index for reloc entries and symbols
>> to resolve conflicting local symbols. For example two objects both
>> contains the ".LC0" symbols, how to figure out which ".LC0" symbol is
>> needed for the reloc entry.
>>
>> I want to use the following layout for reloc part of RAP file .
>>
>> | header | counts(object 1) | reloc entries | counts(object 2) | reloc
>> entries .....
>>
>>
> It looks fine if we finally decide we need locals in a RAP file.
>
> Please note if the RAP format changes we need to change the RAP version
> number. The RAP header has a version number and currently it is hard coded
> in rtems-ld. I think this should be added as a const to the 'rap' namespace
> and formatted into the header. The target side needs to check which version
> it can support, ie up to a specific version and not higher. The version is
> an incrementing number. I will look at adding this soon.
>
>
> Thanks. I'll look into the rap part.

>  The header still contains the total number of reloc entries just like
>> the current implementation.
>> 2. About the local symbols.
>> Now there is a 'symtab_size' variable to indicates how many global
>> symbols are in the rap file.
>> Because I want to include local symbols, I want to add a local symbol
>> table after the global symbol table.
>> | global_symtab_size | local_symtab_size | .......
>> | global symbol table
>> | object1 local_symtab_size | object1 local symbol table
>> | object2 local_symtab_size| object2 local symbol table | ....
>>
>> My current implementation is each reloc entry contains an object index
>> and each symbol contains an object index. But this may consume more
>> space, I prepare to rewrite this using 1 and 2.
>> However I am not sure whether this is ok.
>>
>>
> I am still wondering if we need locals in the RAP file. Could some form of
> incremental linking pass in rtems-ld remove them ?
>
> I am not sure whether using specific gcc options can remove this or not.
I think if use specific options to remove them, there should be a lot work
to be done to resolve the symbol table, strtab and reloc part of the
linker. I want to use my current implementation to implement the other
archs for loader just following the schedule in my proposal ,because the
rtl-mdreloc-(arch).c is relatively independent to the symbols part. Any
advice?

Do you have a simple C piece of code with a compile command line that
> results in an ELF file with these local symbols ? I would like to
> understand why they are present.


The c code in file 3.c :
void hello(int arg)
{
printf("Hello World\n");
}
The compile command:
arm-rtemseabi4.11-gcc 3.c -c -mcpu=cortex-a9 -mthumb -o 3.o


arm-rtemseabi4.11-objdump -Dr 3.o > 3.s

The disassemle code:
3.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <hello>:
   0: b580       push {r7, lr}
   2: b082       sub sp, #8
   4: af00       add r7, sp, #0
   6: 6078       str r0, [r7, #4]
   8: f240 0000 movw r0, #0
8: R_ARM_THM_MOVW_ABS_NC .LC0
   c: f2c0 0000 movt r0, #0
c: R_ARM_THM_MOVT_ABS .LC0
  10: f7ff fffe bl 0 <puts>
10: R_ARM_THM_CALL puts
  14: f107 0708 add.w r7, r7, #8
  18: 46bd       mov sp, r7
  1a: bd80       pop {r7, pc}

Disassembly of section .rodata:

00000000 <.LC0>:
   0: 6c6c6548 cfstr64vs mvdx6, [ip], #-288 ; 0xfffffee0
   4: 6f57206f svcvs 0x0057206f
   8: 00646c72 rsbeq r6, r4, r2, ror ip

Using arm-rtemseabi4.11-readelf -s 3.o, I can see .LC0 is a local symbol:

7: 00000000  0 NOTYPE  LOCAL DEFAULT  5 .LC0

If I do use use -mcpu=cortex-a9, the local symbol ".LC0" does not exist.

Thanks.

>
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130531/0f08dcd5/attachment-0001.html>