llvm dev - Aug 2016 - Replacement for the .stabs directive

Hello Everyone ,

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 .

we are using clang 3.8(with lto) and as you know  that  builtin
assembler / MC streamer  don't have support  fir .stabs  directive.

we are looking to emulate the  above .stabs semantic  i.e associative
the  label_one address with "symbol_name" ,by dwarf or any gas
directives .

Any suggestions,how we can achieve that  ?


Thank you
~Umesh

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.

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>