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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Doerfert, Johannes via llvm-dev

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

linkedin-button

 


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Doerfert, Johannes via llvm-dev
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 <[hidden email]> 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

linkedin-button

 

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Doerfert, Johannes via llvm-dev

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

linkedin-button

 

From: David Blaikie <[hidden email]>
Sent: 02 December 2019 19:51
To: Chirag Patel <[hidden email]>; Adrian Prantl <[hidden email]>; Paul Robinson <[hidden email]>; Jonas Devlieghere <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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

linkedin-button

 

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Doerfert, Johannes via llvm-dev
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 <[hidden email]> 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

linkedin-button

 

From: David Blaikie <[hidden email]>
Sent: 02 December 2019 19:51
To: Chirag Patel <[hidden email]>; Adrian Prantl <[hidden email]>; Paul Robinson <[hidden email]>; Jonas Devlieghere <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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

linkedin-button

 

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Doerfert, Johannes via llvm-dev

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

linkedin-button

 

From: David Blaikie <[hidden email]>
Sent: 03 December 2019 21:31
To: Chirag Patel <[hidden email]>
Cc: Adrian Prantl <[hidden email]>; Paul Robinson <[hidden email]>; Jonas Devlieghere <[hidden email]>; [hidden email]
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 <[hidden email]> 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

linkedin-button

 

From: David Blaikie <[hidden email]>
Sent: 02 December 2019 19:51
To: Chirag Patel <[hidden email]>; Adrian Prantl <[hidden email]>; Paul Robinson <[hidden email]>; Jonas Devlieghere <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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

linkedin-button

 

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Doerfert, Johannes via llvm-dev
I understand the specific savings, but do you have a sense of how much this occurs overall for DWARF of some non-trivial program (like the clang binary)?

I know it's verbose - but it's not especially expensive to maintain the emission of all those bytes (they'd be in a constant array you'd copy into the location expression, I assume - written once) so if there's not much overall size savings and not much parsing savings I'd be inclined to wait until such a thing were standardized rather than introducing an extension.

That's just my tendency on that - quite possible other folks (CC'd) feel differently.

On Wed, Dec 4, 2019 at 12:32 AM Chirag Patel <[hidden email]> wrote:

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

linkedin-button

 

From: David Blaikie <[hidden email]>
Sent: 03 December 2019 21:31
To: Chirag Patel <[hidden email]>
Cc: Adrian Prantl <[hidden email]>; Paul Robinson <[hidden email]>; Jonas Devlieghere <[hidden email]>; [hidden email]
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 <[hidden email]> 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

linkedin-button

 

From: David Blaikie <[hidden email]>
Sent: 02 December 2019 19:51
To: Chirag Patel <[hidden email]>; Adrian Prantl <[hidden email]>; Paul Robinson <[hidden email]>; Jonas Devlieghere <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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

linkedin-button

 

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Doerfert, Johannes via llvm-dev
In reply to this post by Doerfert, Johannes via llvm-dev
In addition to a number of things on the thread I'd like to see this supported in gdb as well if we're going to emit it.

Thanks!

-eric

On Mon, Dec 2, 2019 at 12:14 AM Chirag Patel via llvm-dev <[hidden email]> 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

linkedin-button

 

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev