thr3ads.net - llvm dev - [llvm-dev] addition of vendor dwarf operator extension. [Dec 2019]

If this information is useful, please help other people find it:
Share via:

Chirag Patel via llvm-dev

2019-Dec-03 05:06 UTC

[llvm-dev] addition of vendor dwarf operator extension.

Hello,

Thanks for prompt reply.

Motivation,
In case of debugging of bi-endian dwarf and value known at runtime some of the
raw values needs to be byte swapped to change the endianity. We have a llvm
based compiler which generates such dwarf, TAG_variable marked as big endian and
debugging on little endian host using lldb. The listed operator on dwarf issues
does that, one operator instead of list of operators.

Proposal,
Addition of listed dwarf operator as vender extension in llvm/lldb till it gets
released.

Regards,

Chirag Patel
Software Engineer | Raincode Labs India
Tel: (+91) 080 41159811
Mob: (+91) 9049336744
www.raincodelabs.com<http://www.raincodelabs.com/>
[linkedin-button]<https://in.linkedin.com/in/chirag-patel->

From: David Blaikie <dblaikie at gmail.com>
Sent: 02 December 2019 19:51
To: Chirag Patel <Chirag at raincode.com>; Adrian Prantl <aprantl at
apple.com>; Paul Robinson <paul.robinson at sony.com>; Jonas
Devlieghere <jdevlieghere at apple.com>
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] addition of vendor dwarf operator extension.

There are some vendor extensions already in LLVM/LLDB, though I guess the main
question would be: what's the motivation?

On Mon, Dec 2, 2019 at 3:14 AM Chirag Patel via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hello all,

There is one enhancement request open for dwarfv5,
http://dwarfstd.org/ShowIssue.php?issue=191107.1
The request is for addition of dwarf expression operator to swap the top of the
dwarf stack, the response seems positive but it may take some time till v6.
I like to add that operator as vendor extension but I am not sure how to go
about it for llvm/lldb. Currently I am using it as vendor specific extension on
our local fork.

Does adding it as vender specific extension seems like a good idea? If yes
please provide me the details about adding specific vendor.

Regards,

Chirag Patel
Software Engineer | Raincode Labs India
Tel: (+91) 080 41159811
Mob: (+91) 9049336744
www.raincodelabs.com<http://www.raincodelabs.com/>
[linkedin-button]<https://in.linkedin.com/in/chirag-patel->

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191203/c5ee3b34/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7408 bytes
Desc: image001.png
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191203/c5ee3b34/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 7436 bytes
Desc: image002.png
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191203/c5ee3b34/attachment-0001.png>

David Blaikie via llvm-dev

2019-Dec-03 16:00 UTC

head link

[llvm-dev] addition of vendor dwarf operator extension.

Does this have a significant impact on total DWARF size or performance that
you've observed/have data about?

On Tue, Dec 3, 2019 at 12:06 AM Chirag Patel <Chirag at raincode.com>
wrote:
> Hello,
>
>
>
> Thanks for prompt reply.
>
>
>
> Motivation,
>
> In case of debugging of bi-endian dwarf and value known at runtime some of
> the raw values needs to be byte swapped to change the endianity. We have a
> llvm based compiler which generates such dwarf, TAG_variable marked as big
> endian and debugging on little endian host using lldb. The listed operator
> on dwarf issues does that, one operator instead of list of operators.
>
>
>
> Proposal,
>
> Addition of listed dwarf operator as vender extension in llvm/lldb till it
> gets released.
>
>
>
> Regards,
>
>
>
> *Chirag Patel*
>
> Software Engineer | Raincode Labs India
>
> *Tel*: (+91) 080 41159811
>
> *Mob*: (+91) 9049336744
>
> *www.raincodelabs.com <http://www.raincodelabs.com/>*
>
> [image: linkedin-button] <https://in.linkedin.com/in/chirag-patel->
>
>
>
> *From:* David Blaikie <dblaikie at gmail.com>
> *Sent:* 02 December 2019 19:51
> *To:* Chirag Patel <Chirag at raincode.com>; Adrian Prantl
<aprantl at apple.com>;
> Paul Robinson <paul.robinson at sony.com>; Jonas Devlieghere <
> jdevlieghere at apple.com>
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] addition of vendor dwarf operator extension.
>
>
>
> There are some vendor extensions already in LLVM/LLDB, though I guess the
> main question would be: what's the motivation?
>
>
>
> On Mon, Dec 2, 2019 at 3:14 AM Chirag Patel via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hello all,
>
>
>
> There is one enhancement request open for dwarfv5,
> http://dwarfstd.org/ShowIssue.php?issue=191107.1
>
> The request is for addition of dwarf expression operator to swap the top
> of the dwarf stack, the response seems positive but it may take some time
> till v6.
>
> I like to add that operator as vendor extension but I am not sure how to
> go about it for llvm/lldb. Currently I am using it as vendor specific
> extension on our local fork.
>
>
>
> Does adding it as vender specific extension seems like a good idea? If yes
> please provide me the details about adding specific vendor.
>
>
>
> Regards,
>
>
>
> *Chirag Patel*
>
> Software Engineer | Raincode Labs India
>
> *Tel*: (+91) 080 41159811
>
> *Mob*: (+91) 9049336744
>
> *www.raincodelabs.com <http://www.raincodelabs.com/>*
>
> [image: linkedin-button] <https://in.linkedin.com/in/chirag-patel->
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191203/86322113/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7408 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191203/86322113/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 7436 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191203/86322113/attachment-0001.png>

Chirag Patel via llvm-dev

2019-Dec-04 05:32 UTC

head link

[llvm-dev] addition of vendor dwarf operator extension.

Below is a snippet of the dwarf info that we generate,

0x00000057:   DW_TAG_variable
                DW_AT_name      ("__gbloffset__")
                DW_AT_type      (0x000001e5 "int")
                DW_AT_external  (true)
                DW_AT_decl_file ("…")
                DW_AT_decl_line (8)
                DW_AT_location  (DW_OP_addr 0) // pre linkage
                DW_AT_linkage_name      ("_gblsection__")
                DW_AT_endianity (DW_END_big)

0x00000170:   DW_TAG_variable
                DW_AT_name      ("VAR1")
                DW_AT_type      (0x0000010b "fixed.dec.display.72")
                DW_AT_decl_file ("…")
                DW_AT_decl_line (10)
                DW_AT_location  (DW_OP_addr 0x0, DW_OP_call4 0x57,
DW_OP_deref_size, 4,
DW_OP_dup, DW_OP_constu 0xff, DW_OP_lit0, DW_OP_shl, DW_OP_and, DW_OP_lit24,
DW_OP_shl, DW_OP_swap, DW_OP_dup, DW_OP_constu 0xff, DW_OP_lit8, DW_OP_shl,
DW_OP_and, DW_OP_lit8, DW_OP_shl, DW_OP_swap, DW_OP_dup, DW_OP_constu 0xff,
DW_OP_lit16, DW_OP_shl, DW_OP_and, DW_OP_lit8, DW_OP_shr, DW_OP_swap,
DW_OP_constu 0xff, DW_OP_lit24, DW_OP_shl, DW_OP_and, DW_OP_lit24, DW_OP_shr,
DW_OP_swap, DW_OP_or, DW_OP_or, DW_OP_or, DW_OP_plus)
                DW_AT_linkage_name      ("VAR1")

In above code for location calculation of “VAR1” we change the endianity of
“__gbloffset__” var, it is 32 bit value on 64-bit machine.

In above case DW_OP_byte_swap will replace near about 38 operations(for 32 bit
value), that’s 38-bytes per usage savings on mem footprint and at runtime as
well. I do not have any profiling data.



The use case for DW_OP_byte_swap is, for typed entry we know the size, for raw
data, dwarf operator will consider the generic type and pop the top of the
stack, byte swap it and push the data back on the stack.

Regards,

Chirag Patel
Software Engineer | Raincode Labs India
Tel: (+91) 080 41159811
Mob: (+91) 9049336744
www.raincodelabs.com<http://www.raincodelabs.com/>
[linkedin-button]<https://in.linkedin.com/in/chirag-patel->

From: David Blaikie <dblaikie at gmail.com>
Sent: 03 December 2019 21:31
To: Chirag Patel <Chirag at raincode.com>
Cc: Adrian Prantl <aprantl at apple.com>; Paul Robinson <paul.robinson
at sony.com>; Jonas Devlieghere <jdevlieghere at apple.com>; llvm-dev
at lists.llvm.org
Subject: Re: [llvm-dev] addition of vendor dwarf operator extension.

Does this have a significant impact on total DWARF size or performance that
you've observed/have data about?

On Tue, Dec 3, 2019 at 12:06 AM Chirag Patel <Chirag at
raincode.com<mailto:Chirag at raincode.com>> wrote:
Hello,

Thanks for prompt reply.

Motivation,
In case of debugging of bi-endian dwarf and value known at runtime some of the
raw values needs to be byte swapped to change the endianity. We have a llvm
based compiler which generates such dwarf, TAG_variable marked as big endian and
debugging on little endian host using lldb. The listed operator on dwarf issues
does that, one operator instead of list of operators.

Proposal,
Addition of listed dwarf operator as vender extension in llvm/lldb till it gets
released.

Regards,

Chirag Patel
Software Engineer | Raincode Labs India
Tel: (+91) 080 41159811
Mob: (+91) 9049336744
www.raincodelabs.com<http://www.raincodelabs.com/>
[linkedin-button]<https://in.linkedin.com/in/chirag-patel->

From: David Blaikie <dblaikie at gmail.com<mailto:dblaikie at
gmail.com>>
Sent: 02 December 2019 19:51
To: Chirag Patel <Chirag at raincode.com<mailto:Chirag at
raincode.com>>; Adrian Prantl <aprantl at apple.com<mailto:aprantl
at apple.com>>; Paul Robinson <paul.robinson at
sony.com<mailto:paul.robinson at sony.com>>; Jonas Devlieghere
<jdevlieghere at apple.com<mailto:jdevlieghere at apple.com>>
Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] addition of vendor dwarf operator extension.

There are some vendor extensions already in LLVM/LLDB, though I guess the main
question would be: what's the motivation?

On Mon, Dec 2, 2019 at 3:14 AM Chirag Patel via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hello all,

There is one enhancement request open for dwarfv5,
http://dwarfstd.org/ShowIssue.php?issue=191107.1
The request is for addition of dwarf expression operator to swap the top of the
dwarf stack, the response seems positive but it may take some time till v6.
I like to add that operator as vendor extension but I am not sure how to go
about it for llvm/lldb. Currently I am using it as vendor specific extension on
our local fork.

Does adding it as vender specific extension seems like a good idea? If yes
please provide me the details about adding specific vendor.

Regards,

Chirag Patel
Software Engineer | Raincode Labs India
Tel: (+91) 080 41159811
Mob: (+91) 9049336744
www.raincodelabs.com<http://www.raincodelabs.com/>
[linkedin-button]<https://in.linkedin.com/in/chirag-patel->

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191204/c8d4ccba/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7399 bytes
Desc: image001.png
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191204/c8d4ccba/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 7407 bytes
Desc: image002.png
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191204/c8d4ccba/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 7436 bytes
Desc: image003.png
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191204/c8d4ccba/attachment-0005.png>

llvm dev - Dec 2019 - addition of vendor dwarf operator extension.

[llvm-dev] addition of vendor dwarf operator extension.

[llvm-dev] addition of vendor dwarf operator extension.

[llvm-dev] addition of vendor dwarf operator extension.