[llvm-dev] Replacement for the .stabs directive

[Umesh Kalappa via llvm-dev]

Thank you Jim..

Let's us try on equivalences.

My bad on cross posting,will make sure that next time.

Umesh
On Thursday, August 25, 2016, Jim Wilson <jim.wilson at linaro.org> wrote:

> On 08/19/2016 12:55 PM, Umesh Kalappa via llvm-dev wrote:
>
>> We have the legacy code  ,that uses the .stabs directive quiet often
>> in the source code like
>>
>> .stabs "symbol_name", 100, 0, 0, 0 + .label_one f;
>>
>> .label_one
>>          stmt
>> and ,the above code is wrapped with the  inline asm in the c source file .
>>
>
> Presumably the ".label_one f" is actually "1f" and the ".label_one" is
> "1:".  That would make more sense, as this is a use of the GNU as local
> label feature.
>
> Unfortunately, there is no easy to do this in dwarf, as dwarf debug info
> is split across multiple sections and encoded.  Maybe this could work if
> you handled it like a comdat symbol, but that would be inconvenient, and
> might not even work.  This seems like a option not worth pursuing.
>
> The fact that this worked for stabs is more accident by design.  The code
> never should have been written this way in the first place.
>
> You can make the association between a symbol name and an address by using
> an equivalence.  E.g. you could do
>     asm ("symbol_name = 1f");
> but this puts the symbol_name in the symbol table, which works only if
> symbol_name is unique or maybe unique within its scope if function local.
> If the name was unique, you probably wouldn't have used the ugly stabs
> trick in the first place, so this might not work.  If the symbol names
> aren't unique, maybe you can change the code to make them unique? Using an
> equivalence gives the same effective result as using
>     symbol_name: stmt
>
> Jim
>
> PS Cross posting like this is discouraged.  I would suggest just asking
> assembler questions on the binutils list.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160825/8c7ce5d9/attachment.html>