llvm dev - Nov 2014 - [LLVMdev] [lld][ELF] How to transfer st_other field value from input to output file

STO_MIPS16 and STO_MICROMIPS flags denote that the symbol use a
different "compressed" instructions encoding. Both these flags can be
combined with usual "visibility" flags.

It looks like adding new flag into the contentTypes set might solve
the problem. Thanks for the idea. I try to implement it.

On Thu, Nov 6, 2014 at 6:52 PM, Shankar Easwaran
<shankare at codeaurora.org> wrote:
> One way to do that is to add new visibility / contentTypes (whatever is
> relevant) added for each of the values st_other picks ?
>
> What are the other values st_other can take on MIPS ?
>
> Shankar Easwaran
>
>
> On 11/6/2014 8:50 AM, Simon Atanasyan wrote:
>>
>> Hi,
>>
>> On MIPS st_other field in the ELF symbols table might contain some
>> additional MIPS-specific flags besides visibility ones. These flags
>> should be copied to the output linked file. If YAML => Native
>> conversion is switched off, there is no problem. But in case of the
>> conversion we lose st_other field values.
>>
>> So I need an advice how to keep this information. Is it a good idea to
>> extend YAML and Native format to store these data? Is there any
>> alternative solutions?
-- 
Simon Atanasyan

I was too optimistic. It is possible to use the contentTypes field for
handling STO_MICROMIPS and I have a working solution but the solution
is really ugly. This approach has at least two the following
shortcomings:

1. A MIPS ELF symbol can hold multiple STO_xxx flags stored in the
st_other field (STO_MIPS_PIC, STO_MIPS_MICROMIPS, STO_MIPS_MIPS16
...). Sometimes these flags can be even combined. If we use the
contentTypes field, we have to define a separate ContentType flag for
each such combination. So we get a combinatorics explosion.

2. If we handle MIPS specific ContentType flags together with other
flags, it is pollute the common ELF code. If we factor out the
processing of MIPS specific flags, we have to duplicate code because a
symbol with say STO_MICROMIPS flag should be processed (setup size,
permissions etc) the same way as a regular DefinedAtom::typeCode
symbol.

I considered to create a map symbol name => symbol flags, fill this
map while read object files, and use the map while write a linked
file. But I need to handle both local and global symbols and it is
possible to get symbols with the same name.

It looks like the only solution (if I do not miss anything else) is to
add one more filed to the DefinedAtom class to hold
target/architecture specific set of flags and modify Native and YAML
formats correspondingly. Interpretation of this field is completely
target/architecture dependent.

Any opinions?

On Thu, Nov 6, 2014 at 7:09 PM, Simon Atanasyan <simon at atanasyan.com>
wrote:
> STO_MIPS16 and STO_MICROMIPS flags denote that the symbol use a
> different "compressed" instructions encoding. Both these flags
can be
> combined with usual "visibility" flags.
>
> It looks like adding new flag into the contentTypes set might solve
> the problem. Thanks for the idea. I try to implement it.
>
> On Thu, Nov 6, 2014 at 6:52 PM, Shankar Easwaran
> <shankare at codeaurora.org> wrote:
>> One way to do that is to add new visibility / contentTypes (whatever is
>> relevant) added for each of the values st_other picks ?
>>
>> What are the other values st_other can take on MIPS ?
>>
>> On 11/6/2014 8:50 AM, Simon Atanasyan wrote:
>>> On MIPS st_other field in the ELF symbols table might contain some
>>> additional MIPS-specific flags besides visibility ones. These flags
>>> should be copied to the output linked file. If YAML => Native
>>> conversion is switched off, there is no problem. But in case of the
>>> conversion we lose st_other field values.
>>>
>>> So I need an advice how to keep this information. Is it a good idea
to
>>> extend YAML and Native format to store these data? Is there any
>>> alternative solutions?
-- 
Simon Atanasyan

I had a similar issue with arm vs thumb in mach-o.  Each function’s thumbness is
marked in its symbol table entry.

But it is even worse, a function could change encoding in the middle (only hand
coded assembly could do this).

My solution was to add a new Reference Kind for mach-o which is the current
instruction encoding.  The offsetInAtom() is the offset where the encoding kind
changes.  Usually there is just one at offset zero that sets the encoding for
the whole function.  So determining the thumbness requires scanning the
References.  But it turns out in practice the scan is rarely done because the
result can be cached by whatever algorithm needs that info.

-Nick


On Nov 11, 2014, at 6:50 AM, Simon Atanasyan <simon at atanasyan.com>
wrote:
> I was too optimistic. It is possible to use the contentTypes field for
> handling STO_MICROMIPS and I have a working solution but the solution
> is really ugly. This approach has at least two the following
> shortcomings:
> 
> 1. A MIPS ELF symbol can hold multiple STO_xxx flags stored in the
> st_other field (STO_MIPS_PIC, STO_MIPS_MICROMIPS, STO_MIPS_MIPS16
> ...). Sometimes these flags can be even combined. If we use the
> contentTypes field, we have to define a separate ContentType flag for
> each such combination. So we get a combinatorics explosion.
> 
> 2. If we handle MIPS specific ContentType flags together with other
> flags, it is pollute the common ELF code. If we factor out the
> processing of MIPS specific flags, we have to duplicate code because a
> symbol with say STO_MICROMIPS flag should be processed (setup size,
> permissions etc) the same way as a regular DefinedAtom::typeCode
> symbol.
> 
> I considered to create a map symbol name => symbol flags, fill this
> map while read object files, and use the map while write a linked
> file. But I need to handle both local and global symbols and it is
> possible to get symbols with the same name.
> 
> It looks like the only solution (if I do not miss anything else) is to
> add one more filed to the DefinedAtom class to hold
> target/architecture specific set of flags and modify Native and YAML
> formats correspondingly. Interpretation of this field is completely
> target/architecture dependent.
> 
> Any opinions?
> 
> On Thu, Nov 6, 2014 at 7:09 PM, Simon Atanasyan <simon at
atanasyan.com> wrote:
>> STO_MIPS16 and STO_MICROMIPS flags denote that the symbol use a
>> different "compressed" instructions encoding. Both these
flags can be
>> combined with usual "visibility" flags.
>> 
>> It looks like adding new flag into the contentTypes set might solve
>> the problem. Thanks for the idea. I try to implement it.
>> 
>> On Thu, Nov 6, 2014 at 6:52 PM, Shankar Easwaran
>> <shankare at codeaurora.org> wrote:
>>> One way to do that is to add new visibility / contentTypes
(whatever is
>>> relevant) added for each of the values st_other picks ?
>>> 
>>> What are the other values st_other can take on MIPS ?
>>> 
>>> On 11/6/2014 8:50 AM, Simon Atanasyan wrote:
>>>> On MIPS st_other field in the ELF symbols table might contain
some
>>>> additional MIPS-specific flags besides visibility ones. These
flags
>>>> should be copied to the output linked file. If YAML =>
Native
>>>> conversion is switched off, there is no problem. But in case of
the
>>>> conversion we lose st_other field values.
>>>> 
>>>> So I need an advice how to keep this information. Is it a good
idea to
>>>> extend YAML and Native format to store these data? Is there any
>>>> alternative solutions?
> 
> -- 
> Simon Atanasyan