DebugInfo work contribution and update.

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

DebugInfo work contribution and update.

Kristof Beyls via cfe-dev
Hi llvm-dev, cfe-dev,

It's been a while since our team is investigating DebugInfo in LLVM, we're looking forward to contribute and enhance in LLVM DebugInfo. 

We,'ve been investigating mostly on DWARF-5 aspects -- couple of them to mention--
1. Language aspects
2. Location mostly optimized out ones
3. DebugInfo conformance to DWARF-5

To avoid getting conflicted with some body else's work and avoiding redundancy. We would like to know the over-all state of current community developments happening WRT DWARF-5. 

As of now, we're working on --
PR 43263, 43622 -- reported today {Just Now}

we'll be up-streaming patches for these. 

Please let us know your thoughts, and anything else that's relevant that we need to aware of before picking up.

Thanks in anticipation!
Sourabh Singh Tomar



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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev
+some other debugger people (Pavel - wasn't sure which email address you prefer, feel free to let me know (privately or publicly) for future reference)

I work at Google & we're certainly interested in DWARFv5 compliance - I'm currently working on improving debug_loclist emission to share more address pool entries ( https://reviews.llvm.org/D68620 ) which includes some improvements to llvm-dwarfdump to go with that. (Pavel's working on further improvements https://reviews.llvm.org/D68271 )

I haven't looked at/started on the loclist issue (PR43622) - so if you want to look at that, that's fine by me.

Are you also interested in the debugger side of things? GDB's DWARFv5 support is pretty incomplete & Ali's already looking at some of that, and I might get to the debug_loclist improvements necessary - but if someone else wants to do that before me, I won't complain.

Not sure of any other major holes in LLVM's DWARFv5 support, but they might be out there, for sure.

On Wed, Oct 9, 2019 at 9:37 AM Sourabh Singh Tomar via llvm-dev <[hidden email]> wrote:
Hi llvm-dev, cfe-dev,

It's been a while since our team is investigating DebugInfo in LLVM, we're looking forward to contribute and enhance in LLVM DebugInfo. 

We,'ve been investigating mostly on DWARF-5 aspects -- couple of them to mention--
1. Language aspects
2. Location mostly optimized out ones
3. DebugInfo conformance to DWARF-5

To avoid getting conflicted with some body else's work and avoiding redundancy. We would like to know the over-all state of current community developments happening WRT DWARF-5. 

As of now, we're working on --
PR 43263, 43622 -- reported today {Just Now}

we'll be up-streaming patches for these. 

Please let us know your thoughts, and anything else that's relevant that we need to aware of before picking up.

Thanks in anticipation!
Sourabh Singh Tomar


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

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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev
Thanks, David for updating us.

Regarding, mail address, can use anyone{@gmail or @amd}. but [hidden email] works best for me for mailing lists related stuff.

Regarding, GDB side of DWARFv5 side of things, we've testing GDB-8.3 WRT DWARFv5 clang and gcc binaries to get better idea of debuggability of clang generated binaries with GDB. 
Primary motivation being GDB better handling of gcc generated binaries, compared to clang.

We've been also tracking Ali's patches in gdb mailing list. Jini can update you better on, this one. Will ask her share update on this one.

Thanks,
Sourabh



On Wed, Oct 9, 2019 at 10:59 PM David Blaikie <[hidden email]> wrote:
+some other debugger people (Pavel - wasn't sure which email address you prefer, feel free to let me know (privately or publicly) for future reference)

I work at Google & we're certainly interested in DWARFv5 compliance - I'm currently working on improving debug_loclist emission to share more address pool entries ( https://reviews.llvm.org/D68620 ) which includes some improvements to llvm-dwarfdump to go with that. (Pavel's working on further improvements https://reviews.llvm.org/D68271 )

I haven't looked at/started on the loclist issue (PR43622) - so if you want to look at that, that's fine by me.

Are you also interested in the debugger side of things? GDB's DWARFv5 support is pretty incomplete & Ali's already looking at some of that, and I might get to the debug_loclist improvements necessary - but if someone else wants to do that before me, I won't complain.

Not sure of any other major holes in LLVM's DWARFv5 support, but they might be out there, for sure.

On Wed, Oct 9, 2019 at 9:37 AM Sourabh Singh Tomar via llvm-dev <[hidden email]> wrote:
Hi llvm-dev, cfe-dev,

It's been a while since our team is investigating DebugInfo in LLVM, we're looking forward to contribute and enhance in LLVM DebugInfo. 

We,'ve been investigating mostly on DWARF-5 aspects -- couple of them to mention--
1. Language aspects
2. Location mostly optimized out ones
3. DebugInfo conformance to DWARF-5

To avoid getting conflicted with some body else's work and avoiding redundancy. We would like to know the over-all state of current community developments happening WRT DWARF-5. 

As of now, we're working on --
PR 43263, 43622 -- reported today {Just Now}

we'll be up-streaming patches for these. 

Please let us know your thoughts, and anything else that's relevant that we need to aware of before picking up.

Thanks in anticipation!
Sourabh Singh Tomar


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

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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev

Welcome Sourabh,

 

There are many bits of DWARF-5 that haven’t been implemented.  I know there is currently no big push within Sony to “fill in the corners” for v5, as we have been more focused on quality of debug info for optimized code (not losing information or reporting incorrect information) and the Dexter tool.  There is no shortage of ways in which debug info for optimized code could be better; in general we are trying to post bug reports for anything we find that we’re not working on right away.

 

I think you are doing the right thing as far as coordinating with other people: Watch the llvm-commits and cfe-commits lists to notice when people are posting patches; post your own patches; and ask on the dev lists.  If you decide to work on something that was reported as a bug, post a note there or assign the bug to yourself.

 

I looked up the two PRs you cited; PR43622 is likely a simple oversight that should be easy to fix.  PR43263 doesn’t appear to be related to debug info, was that a typo?

--paulr

 

From: Sourabh Singh Tomar <[hidden email]>
Sent: Wednesday, October 09, 2019 2:38 PM
To: David Blaikie <[hidden email]>
Cc: Adrian Prantl <[hidden email]>; Robinson, Paul <[hidden email]>; Eric Christopher <[hidden email]>; Jonas Devlieghere <[hidden email]>; Ali Tamur <[hidden email]>; Pavel Labath <[hidden email]>; Pavel Labath <[hidden email]>; [hidden email]; Clang Dev <[hidden email]>; George, Jini Susan <[hidden email]>; [hidden email]
Subject: Re: [llvm-dev] DebugInfo work contribution and update.

 

Thanks, David for updating us.

 

Regarding, mail address, can use anyone{@gmail or @amd}. but [hidden email] works best for me for mailing lists related stuff.

 

Regarding, GDB side of DWARFv5 side of things, we've testing GDB-8.3 WRT DWARFv5 clang and gcc binaries to get better idea of debuggability of clang generated binaries with GDB. 

Primary motivation being GDB better handling of gcc generated binaries, compared to clang.

 

We've been also tracking Ali's patches in gdb mailing list. Jini can update you better on, this one. Will ask her share update on this one.

 

Thanks,

Sourabh

 

 

 

On Wed, Oct 9, 2019 at 10:59 PM David Blaikie <[hidden email]> wrote:

+some other debugger people (Pavel - wasn't sure which email address you prefer, feel free to let me know (privately or publicly) for future reference)

I work at Google & we're certainly interested in DWARFv5 compliance - I'm currently working on improving debug_loclist emission to share more address pool entries ( https://reviews.llvm.org/D68620 ) which includes some improvements to llvm-dwarfdump to go with that. (Pavel's working on further improvements https://reviews.llvm.org/D68271 )

I haven't looked at/started on the loclist issue (PR43622) - so if you want to look at that, that's fine by me.

Are you also interested in the debugger side of things? GDB's DWARFv5 support is pretty incomplete & Ali's already looking at some of that, and I might get to the debug_loclist improvements necessary - but if someone else wants to do that before me, I won't complain.

Not sure of any other major holes in LLVM's DWARFv5 support, but they might be out there, for sure.

 

On Wed, Oct 9, 2019 at 9:37 AM Sourabh Singh Tomar via llvm-dev <[hidden email]> wrote:

Hi llvm-dev, cfe-dev,

 

It's been a while since our team is investigating DebugInfo in LLVM, we're looking forward to contribute and enhance in LLVM DebugInfo. 

 

We,'ve been investigating mostly on DWARF-5 aspects -- couple of them to mention--

1. Language aspects

2. Location mostly optimized out ones

3. DebugInfo conformance to DWARF-5

 

To avoid getting conflicted with some body else's work and avoiding redundancy. We would like to know the over-all state of current community developments happening WRT DWARF-5. 

 

As of now, we're working on --

PR 43263, 43622 -- reported today {Just Now}

 

we'll be up-streaming patches for these. 

 

Please let us know your thoughts, and anything else that's relevant that we need to aware of before picking up.

 

Thanks in anticipation!

Sourabh Singh Tomar

 

 

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


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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev


On Wed, Oct 9, 2019 at 11:59 AM Robinson, Paul <[hidden email]> wrote:

Welcome Sourabh,

 

There are many bits of DWARF-5 that haven’t been implemented.


Got a short list, by chance?
 

  I know there is currently no big push within Sony to “fill in the corners” for v5, as we have been more focused on quality of debug info for optimized code (not losing information or reporting incorrect information) and the Dexter tool.  There is no shortage of ways in which debug info for optimized code could be better; in general we are trying to post bug reports for anything we find that we’re not working on right away.

 

I think you are doing the right thing as far as coordinating with other people: Watch the llvm-commits and cfe-commits lists to notice when people are posting patches; post your own patches; and ask on the dev lists.  If you decide to work on something that was reported as a bug, post a note there or assign the bug to yourself.

 

I looked up the two PRs you cited; PR43622 is likely a simple oversight that should be easy to fix.  PR43263 doesn’t appear to be related to debug info, was that a typo?

--paulr

 

From: Sourabh Singh Tomar <[hidden email]>
Sent: Wednesday, October 09, 2019 2:38 PM
To: David Blaikie <[hidden email]>
Cc: Adrian Prantl <[hidden email]>; Robinson, Paul <[hidden email]>; Eric Christopher <[hidden email]>; Jonas Devlieghere <[hidden email]>; Ali Tamur <[hidden email]>; Pavel Labath <[hidden email]>; Pavel Labath <[hidden email]>; [hidden email]; Clang Dev <[hidden email]>; George, Jini Susan <[hidden email]>; [hidden email]
Subject: Re: [llvm-dev] DebugInfo work contribution and update.

 

Thanks, David for updating us.

 

Regarding, mail address, can use anyone{@gmail or @amd}. but [hidden email] works best for me for mailing lists related stuff.

 

Regarding, GDB side of DWARFv5 side of things, we've testing GDB-8.3 WRT DWARFv5 clang and gcc binaries to get better idea of debuggability of clang generated binaries with GDB. 

Primary motivation being GDB better handling of gcc generated binaries, compared to clang.

 

We've been also tracking Ali's patches in gdb mailing list. Jini can update you better on, this one. Will ask her share update on this one.

 

Thanks,

Sourabh

 

 

 

On Wed, Oct 9, 2019 at 10:59 PM David Blaikie <[hidden email]> wrote:

+some other debugger people (Pavel - wasn't sure which email address you prefer, feel free to let me know (privately or publicly) for future reference)

I work at Google & we're certainly interested in DWARFv5 compliance - I'm currently working on improving debug_loclist emission to share more address pool entries ( https://reviews.llvm.org/D68620 ) which includes some improvements to llvm-dwarfdump to go with that. (Pavel's working on further improvements https://reviews.llvm.org/D68271 )

I haven't looked at/started on the loclist issue (PR43622) - so if you want to look at that, that's fine by me.

Are you also interested in the debugger side of things? GDB's DWARFv5 support is pretty incomplete & Ali's already looking at some of that, and I might get to the debug_loclist improvements necessary - but if someone else wants to do that before me, I won't complain.

Not sure of any other major holes in LLVM's DWARFv5 support, but they might be out there, for sure.

 

On Wed, Oct 9, 2019 at 9:37 AM Sourabh Singh Tomar via llvm-dev <[hidden email]> wrote:

Hi llvm-dev, cfe-dev,

 

It's been a while since our team is investigating DebugInfo in LLVM, we're looking forward to contribute and enhance in LLVM DebugInfo. 

 

We,'ve been investigating mostly on DWARF-5 aspects -- couple of them to mention--

1. Language aspects

2. Location mostly optimized out ones

3. DebugInfo conformance to DWARF-5

 

To avoid getting conflicted with some body else's work and avoiding redundancy. We would like to know the over-all state of current community developments happening WRT DWARF-5. 

 

As of now, we're working on --

PR 43263, 43622 -- reported today {Just Now}

 

we'll be up-streaming patches for these. 

 

Please let us know your thoughts, and anything else that's relevant that we need to aware of before picking up.

 

Thanks in anticipation!

Sourabh Singh Tomar

 

 

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


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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev
In reply to this post by Kristof Beyls via cfe-dev
Thanks for correcting this Paul.

Yes, Typo indeed.
it's PR43622  and PR43623.

I'll keep a note of your advice.

Thanks!
--Sourabh Singh Tomar

On Thu, Oct 10, 2019 at 12:29 AM Robinson, Paul <[hidden email]> wrote:

Welcome Sourabh,

 

There are many bits of DWARF-5 that haven’t been implemented.  I know there is currently no big push within Sony to “fill in the corners” for v5, as we have been more focused on quality of debug info for optimized code (not losing information or reporting incorrect information) and the Dexter tool.  There is no shortage of ways in which debug info for optimized code could be better; in general we are trying to post bug reports for anything we find that we’re not working on right away.

 

I think you are doing the right thing as far as coordinating with other people: Watch the llvm-commits and cfe-commits lists to notice when people are posting patches; post your own patches; and ask on the dev lists.  If you decide to work on something that was reported as a bug, post a note there or assign the bug to yourself.

 

I looked up the two PRs you cited; PR43622 is likely a simple oversight that should be easy to fix.  PR43263 doesn’t appear to be related to debug info, was that a typo?

--paulr

 

From: Sourabh Singh Tomar <[hidden email]>
Sent: Wednesday, October 09, 2019 2:38 PM
To: David Blaikie <[hidden email]>
Cc: Adrian Prantl <[hidden email]>; Robinson, Paul <[hidden email]>; Eric Christopher <[hidden email]>; Jonas Devlieghere <[hidden email]>; Ali Tamur <[hidden email]>; Pavel Labath <[hidden email]>; Pavel Labath <[hidden email]>; [hidden email]; Clang Dev <[hidden email]>; George, Jini Susan <[hidden email]>; [hidden email]
Subject: Re: [llvm-dev] DebugInfo work contribution and update.

 

Thanks, David for updating us.

 

Regarding, mail address, can use anyone{@gmail or @amd}. but [hidden email] works best for me for mailing lists related stuff.

 

Regarding, GDB side of DWARFv5 side of things, we've testing GDB-8.3 WRT DWARFv5 clang and gcc binaries to get better idea of debuggability of clang generated binaries with GDB. 

Primary motivation being GDB better handling of gcc generated binaries, compared to clang.

 

We've been also tracking Ali's patches in gdb mailing list. Jini can update you better on, this one. Will ask her share update on this one.

 

Thanks,

Sourabh

 

 

 

On Wed, Oct 9, 2019 at 10:59 PM David Blaikie <[hidden email]> wrote:

+some other debugger people (Pavel - wasn't sure which email address you prefer, feel free to let me know (privately or publicly) for future reference)

I work at Google & we're certainly interested in DWARFv5 compliance - I'm currently working on improving debug_loclist emission to share more address pool entries ( https://reviews.llvm.org/D68620 ) which includes some improvements to llvm-dwarfdump to go with that. (Pavel's working on further improvements https://reviews.llvm.org/D68271 )

I haven't looked at/started on the loclist issue (PR43622) - so if you want to look at that, that's fine by me.

Are you also interested in the debugger side of things? GDB's DWARFv5 support is pretty incomplete & Ali's already looking at some of that, and I might get to the debug_loclist improvements necessary - but if someone else wants to do that before me, I won't complain.

Not sure of any other major holes in LLVM's DWARFv5 support, but they might be out there, for sure.

 

On Wed, Oct 9, 2019 at 9:37 AM Sourabh Singh Tomar via llvm-dev <[hidden email]> wrote:

Hi llvm-dev, cfe-dev,

 

It's been a while since our team is investigating DebugInfo in LLVM, we're looking forward to contribute and enhance in LLVM DebugInfo. 

 

We,'ve been investigating mostly on DWARF-5 aspects -- couple of them to mention--

1. Language aspects

2. Location mostly optimized out ones

3. DebugInfo conformance to DWARF-5

 

To avoid getting conflicted with some body else's work and avoiding redundancy. We would like to know the over-all state of current community developments happening WRT DWARF-5. 

 

As of now, we're working on --

PR 43263, 43622 -- reported today {Just Now}

 

we'll be up-streaming patches for these. 

 

Please let us know your thoughts, and anything else that's relevant that we need to aware of before picking up.

 

Thanks in anticipation!

Sourabh Singh Tomar

 

 

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


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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev
In reply to this post by Kristof Beyls via cfe-dev
> From: David Blaikie <[hidden email]>
>> On Wed, Oct 9, 2019 at 11:59 AM Robinson, Paul <mailto:[hidden email]> wrote:
>> There are many bits of DWARF-5 that haven’t been implemented.
>
> Got a short list, by chance?

I can't say I've been keeping track of all that has gone in, but based
on the list that I came up with when I was sizing the initial DWARF 5
work, things that might not be done include:

Default location entry
Inline namespace attribute
Reference-qualified member functions
"auto" return type
Type/item alignment
Defaulted template parameter
Atomic type modifier
DW_OP_implicit_pointer
.debug_macro section
Typed expressions
Supplementary objects

Things I have noticed going in recently:

Call-site and entry-value stuff (is that complete?)
New language/dialect codes
Deleted/defaulted members is in progress
"noreturn" functions is in progress

I can't remember whether split-DWARF is fully v5 compliant...

If any items above are in fact done, my apologies and VERY happy to be
corrected.
--paulr

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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev


> On Oct 9, 2019, at 1:33 PM, Robinson, Paul <[hidden email]> wrote:
>
>> From: David Blaikie <[hidden email]>
>>> On Wed, Oct 9, 2019 at 11:59 AM Robinson, Paul <mailto:[hidden email]> wrote:
>>> There are many bits of DWARF-5 that haven’t been implemented.
>>
>> Got a short list, by chance?
>
> I can't say I've been keeping track of all that has gone in, but based
> on the list that I came up with when I was sizing the initial DWARF 5
> work, things that might not be done include:
>
> Default location entry
> Inline namespace attribute

I think we may have this one already!

commit dbfda63695272c2d12a6a61b18b52d3961d8e1a8
Author: Adrian Prantl <[hidden email]>
Date:   Thu Nov 3 19:42:02 2016 +0000

    Add DWARF debug info support for C++11 inline namespaces.
    This implements the DWARF 5 DW_AT_export_symbols feature:
    http://dwarfstd.org/ShowIssue.php?issue=141212.1
   
    <rdar://problem/18616046>
   
    llvm-svn: 285959


> Reference-qualified member functions
> "auto" return type
> Type/item alignment
> Defaulted template parameter
> Atomic type modifier
> DW_OP_implicit_pointer
> .debug_macro section
> Typed expressions
> Supplementary objects
>
> Things I have noticed going in recently:
>
> Call-site and entry-value stuff (is that complete?)
> New language/dialect codes
> Deleted/defaulted members is in progress
> "noreturn" functions is in progress
>
> I can't remember whether split-DWARF is fully v5 compliant...
>
> If any items above are in fact done, my apologies and VERY happy to be
> corrected.
> --paulr
>

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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev
In reply to this post by Kristof Beyls via cfe-dev

Hi David,

 

Yes, we are interested in the gdb side of things too – as Sourabh said, we have been following Ali’s patches. I think we will co-ordinate with Ali to see what gdb support for DWARF5 we can add so that we don’t tread on each other’s toes.

 

Thanks!

Jini.

 

From: David Blaikie <[hidden email]>
Sent: Wednesday, October 9, 2019 10:59 PM
To: Sourabh Singh Tomar <[hidden email]>; Adrian Prantl <[hidden email]>; Paul Robinson <[hidden email]>; Eric Christopher <[hidden email]>; Jonas Devlieghere <[hidden email]>; Ali Tamur <[hidden email]>; Pavel Labath <[hidden email]>; Pavel Labath <[hidden email]>
Cc: [hidden email]; Clang Dev <[hidden email]>; George, Jini Susan <[hidden email]>; Tomar, Sourabh Singh <[hidden email]>
Subject: Re: [llvm-dev] DebugInfo work contribution and update.

 

[CAUTION: External Email]

+some other debugger people (Pavel - wasn't sure which email address you prefer, feel free to let me know (privately or publicly) for future reference)

I work at Google & we're certainly interested in DWARFv5 compliance - I'm currently working on improving debug_loclist emission to share more address pool entries ( https://reviews.llvm.org/D68620 ) which includes some improvements to llvm-dwarfdump to go with that. (Pavel's working on further improvements https://reviews.llvm.org/D68271 )

I haven't looked at/started on the loclist issue (PR43622) - so if you want to look at that, that's fine by me.

Are you also interested in the debugger side of things? GDB's DWARFv5 support is pretty incomplete & Ali's already looking at some of that, and I might get to the debug_loclist improvements necessary - but if someone else wants to do that before me, I won't complain.

Not sure of any other major holes in LLVM's DWARFv5 support, but they might be out there, for sure.

 

On Wed, Oct 9, 2019 at 9:37 AM Sourabh Singh Tomar via llvm-dev <[hidden email]> wrote:

Hi llvm-dev, cfe-dev,

 

It's been a while since our team is investigating DebugInfo in LLVM, we're looking forward to contribute and enhance in LLVM DebugInfo. 

 

We,'ve been investigating mostly on DWARF-5 aspects -- couple of them to mention--

1. Language aspects

2. Location mostly optimized out ones

3. DebugInfo conformance to DWARF-5

 

To avoid getting conflicted with some body else's work and avoiding redundancy. We would like to know the over-all state of current community developments happening WRT DWARF-5. 

 

As of now, we're working on --

PR 43263, 43622 -- reported today {Just Now}

 

we'll be up-streaming patches for these. 

 

Please let us know your thoughts, and anything else that's relevant that we need to aware of before picking up.

 

Thanks in anticipation!

Sourabh Singh Tomar

 

 

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


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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev
In reply to this post by Kristof Beyls via cfe-dev

Hi David,

 

Yes, we are interested in the gdb side of things too – as Sourabh said, we have been following Ali’s patches. I think we will co-ordinate with Ali to see what gdb support for DWARF5 we can add so that we don’t tread on each other’s toes.

 

Thanks!

Jini.


On Wed, Oct 9, 2019 at 11:00 PM David Blaikie via llvm-dev <[hidden email]> wrote:
+some other debugger people (Pavel - wasn't sure which email address you prefer, feel free to let me know (privately or publicly) for future reference)

I work at Google & we're certainly interested in DWARFv5 compliance - I'm currently working on improving debug_loclist emission to share more address pool entries ( https://reviews.llvm.org/D68620 ) which includes some improvements to llvm-dwarfdump to go with that. (Pavel's working on further improvements https://reviews.llvm.org/D68271 )

I haven't looked at/started on the loclist issue (PR43622) - so if you want to look at that, that's fine by me.

Are you also interested in the debugger side of things? GDB's DWARFv5 support is pretty incomplete & Ali's already looking at some of that, and I might get to the debug_loclist improvements necessary - but if someone else wants to do that before me, I won't complain.

Not sure of any other major holes in LLVM's DWARFv5 support, but they might be out there, for sure.

On Wed, Oct 9, 2019 at 9:37 AM Sourabh Singh Tomar via llvm-dev <[hidden email]> wrote:
Hi llvm-dev, cfe-dev,

It's been a while since our team is investigating DebugInfo in LLVM, we're looking forward to contribute and enhance in LLVM DebugInfo. 

We,'ve been investigating mostly on DWARF-5 aspects -- couple of them to mention--
1. Language aspects
2. Location mostly optimized out ones
3. DebugInfo conformance to DWARF-5

To avoid getting conflicted with some body else's work and avoiding redundancy. We would like to know the over-all state of current community developments happening WRT DWARF-5. 

As of now, we're working on --
PR 43263, 43622 -- reported today {Just Now}

we'll be up-streaming patches for these. 

Please let us know your thoughts, and anything else that's relevant that we need to aware of before picking up.

Thanks in anticipation!
Sourabh Singh Tomar


_______________________________________________
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

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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev
In reply to this post by Kristof Beyls via cfe-dev
Thanks for the list, Paul. This is quite helpful. DW_OP_implicit_pointer is something that we are looking into currently. I believe that  "Reference-qualified member functions" has also been implemented.

Thanks!
Jini.

 

On Thu, Oct 10, 2019 at 2:03 AM Robinson, Paul via llvm-dev <[hidden email]> wrote:
> From: David Blaikie <[hidden email]>
>> On Wed, Oct 9, 2019 at 11:59 AM Robinson, Paul <mailto:[hidden email]> wrote:
>> There are many bits of DWARF-5 that haven’t been implemented.
>
> Got a short list, by chance?

I can't say I've been keeping track of all that has gone in, but based
on the list that I came up with when I was sizing the initial DWARF 5
work, things that might not be done include:

Default location entry
Inline namespace attribute
Reference-qualified member functions
"auto" return type
Type/item alignment
Defaulted template parameter
Atomic type modifier
DW_OP_implicit_pointer
.debug_macro section
Typed expressions
Supplementary objects

Things I have noticed going in recently:

Call-site and entry-value stuff (is that complete?)
New language/dialect codes
Deleted/defaulted members is in progress
"noreturn" functions is in progress

I can't remember whether split-DWARF is fully v5 compliant...

If any items above are in fact done, my apologies and VERY happy to be
corrected.
--paulr

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

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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev
In reply to this post by Kristof Beyls via cfe-dev
Hello Sourabh, David, others,

Like David said I am currently looking at the consumption side of
debug_loclists, and my main angle is being able to reuse that parser in
lldb (which has its own dwarf parser for the most part, but it is trying
to move away from that). However, I've been busy with other stuff lately
and so I haven't done much work there, but hopefully things will clear
up now.

On 09/10/2019 21:11, David Blaikie wrote:

>
>
> On Wed, Oct 9, 2019 at 11:59 AM Robinson, Paul <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Welcome Sourabh,____
>
>     __ __
>
>     There are many bits of DWARF-5 that haven’t been implemented.
>
>
> Got a short list, by chance?

My pet missing feature is the debug_names+type units combo, which
currently does not work due to the interaction of opportunistic type
unit creation and eager insertion of type names into the index.

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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev
In reply to this post by Kristof Beyls via cfe-dev


On Wed, Oct 9, 2019 at 1:33 PM Robinson, Paul <[hidden email]> wrote:
> From: David Blaikie <[hidden email]>
>> On Wed, Oct 9, 2019 at 11:59 AM Robinson, Paul <mailto:[hidden email]> wrote:
>> There are many bits of DWARF-5 that haven’t been implemented.
>
> Got a short list, by chance?

I can't say I've been keeping track of all that has gone in, but based
on the list that I came up with when I was sizing the initial DWARF 5
work, things that might not be done include:

Default location entry
Inline namespace attribute
Reference-qualified member functions
"auto" return type
Type/item alignment
Defaulted template parameter
Atomic type modifier
DW_OP_implicit_pointer
.debug_macro section
Typed expressions
Supplementary objects

Ah, thanks for the list - mostly I'm interested in cases where Clang's output is not valid DWARFv5 when requested - the new features DWARFv5 enables/allows but doesn't require are lower priority to me. Which I don't think too much is left - DWARFv5 loclists in split DWARF is one I know of & might get to if someone else doesn't do it before me - I'm currently improving loclist emission (quality of implementation - using fewer address pool entries & just general code cleanup to share some of teh implementation with rnglist emission, not a compliance issue)
 

Things I have noticed going in recently:

Call-site and entry-value stuff (is that complete?)
New language/dialect codes
Deleted/defaulted members is in progress
"noreturn" functions is in progress

I can't remember whether split-DWARF is fully v5 compliant...

If any items above are in fact done, my apologies and VERY happy to be
corrected.
--paulr


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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev
> Ah, thanks for the list - mostly I'm interested in cases where Clang's
> output is not valid DWARFv5 when requested - the new features DWARFv5
> enables/allows but doesn't require are lower priority to me. Which I
> don't think too much is left - DWARFv5 loclists in split DWARF is one
> I know of & might get to if someone else doesn't do it before me - I'm
> currently improving loclist emission (quality of implementation - using
> fewer address pool entries & just general code cleanup to share some of
> teh implementation with rnglist emission, not a compliance issue)

You might want to look at default location entry then; particularly if a
variable moves around but has a stack home, it can reduce the number of
entries and maybe eliminate some .debug_addr references.
--paulr

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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev


On Thu, Oct 10, 2019 at 1:18 PM Robinson, Paul <[hidden email]> wrote:
> Ah, thanks for the list - mostly I'm interested in cases where Clang's
> output is not valid DWARFv5 when requested - the new features DWARFv5
> enables/allows but doesn't require are lower priority to me. Which I
> don't think too much is left - DWARFv5 loclists in split DWARF is one
> I know of & might get to if someone else doesn't do it before me - I'm
> currently improving loclist emission (quality of implementation - using
> fewer address pool entries & just general code cleanup to share some of
> teh implementation with rnglist emission, not a compliance issue)

You might want to look at default location entry then; particularly if a
variable moves around but has a stack home, it can reduce the number of
entries and maybe eliminate some .debug_addr references.

I don't think it'd reduce debug_addr references - I'm setting it up to only use the base address of the function start and everything's offset pairs from there, so loclists shouldn't create any addr entries, only using existing ones needed for the function's low_pc/CU's ranges, etc.

I don't know what our current variable location tracking would ever likely manage to preserve the location information enough for it to cover the whole scope (or at least not often) & then pick a default location as the most common used location across that scope. (I'm guessing almost any optimizations will cause some part of the address range of the enclosing scope to lose locations).

If we do actually hit that case (probably would be worth building a DWARF statistic (even a temporary one) that tests whether a location list describes the entire address range of the enclosing scope - I'm guessing that happens roughly never at the moment) we could look into improving the DWARF emission to be more compact by using the default.

- Dave
 
--paulr


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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev
Hi Everybody,

Just wanted to drop a note regarding status debug_macro DWARFv5 section. 
I've started looking into debug_macro section. 
Soon incremental patches will follow.

One query regarding clang behavior for debug_macinfo section -- Now, I understand that to enable macro information and for gdb able to expand macros, clang needs "-fdebug-macro". Default is not to emit debug info for macros.

But consider below dump, is this Okay to have a empty{Size 1 byte} debug_macinfo section to be emitted ?? when we are not emitting macro info at all. 
Should we stop emitting this ?? this is on purpose.
Note: this behavior persists, even when specifying "-fno-debug-macro" option explicitly.

sourabh@llvm-slrz2:~/work/dwarf/c_c++/macro$ upstream-clang -ggdb min_macro.c
sourabh@llvm-slrz2:~/work/dwarf/c_c++/macro$ upstream-llvm-readelf -S a.out | awk /debug/
  [23] .debug_info       PROGBITS        0000000000000000 0030bc 00005a 00      0   0  1
  [24] .debug_abbrev     PROGBITS        0000000000000000 003116 000043 00      0   0  1
  [25] .debug_line       PROGBITS        0000000000000000 003159 000045 00      0   0  1
  [26] .debug_str        PROGBITS        0000000000000000 00319e 0000a5 01  MS  0   0  1
  [27] .debug_macinfo    PROGBITS        0000000000000000 003243 000001 00      0   0  1

sourabh@llvm-slrz2:~/work/dwarf/c_c++/macro$ upstream-llvm-dwarfdump -debug-macro a.out
a.out:  file format ELF64-x86-64
.debug_macinfo contents:

sourabh@llvm-slrz2:~/work/dwarf/c_c++/macro$ upstream-llvm-readelf -x.debug_macinfo a.out
Hex dump of section '.debug_macinfo':
0x00000000 00

Thanks,
Sourabh.

On Fri, Oct 11, 2019 at 1:58 AM David Blaikie <[hidden email]> wrote:


On Thu, Oct 10, 2019 at 1:18 PM Robinson, Paul <[hidden email]> wrote:
> Ah, thanks for the list - mostly I'm interested in cases where Clang's
> output is not valid DWARFv5 when requested - the new features DWARFv5
> enables/allows but doesn't require are lower priority to me. Which I
> don't think too much is left - DWARFv5 loclists in split DWARF is one
> I know of & might get to if someone else doesn't do it before me - I'm
> currently improving loclist emission (quality of implementation - using
> fewer address pool entries & just general code cleanup to share some of
> teh implementation with rnglist emission, not a compliance issue)

You might want to look at default location entry then; particularly if a
variable moves around but has a stack home, it can reduce the number of
entries and maybe eliminate some .debug_addr references.

I don't think it'd reduce debug_addr references - I'm setting it up to only use the base address of the function start and everything's offset pairs from there, so loclists shouldn't create any addr entries, only using existing ones needed for the function's low_pc/CU's ranges, etc.

I don't know what our current variable location tracking would ever likely manage to preserve the location information enough for it to cover the whole scope (or at least not often) & then pick a default location as the most common used location across that scope. (I'm guessing almost any optimizations will cause some part of the address range of the enclosing scope to lose locations).

If we do actually hit that case (probably would be worth building a DWARF statistic (even a temporary one) that tests whether a location list describes the entire address range of the enclosing scope - I'm guessing that happens roughly never at the moment) we could look into improving the DWARF emission to be more compact by using the default.

- Dave
 
--paulr


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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev
> One query regarding clang behavior for debug_macinfo section -- Now, I
> understand that to enable macro information and for gdb able to expand
> macros, clang needs "-fdebug-macro". Default is not to emit debug info
> for macros.
>
> But consider below dump, is this Okay to have a empty{Size 1 byte}
> debug_macinfo section to be emitted ?? when we are not emitting macro
> info at all. 
> Should we stop emitting this ?? this is on purpose.
> Note: this behavior persists, even when specifying "-fno-debug-macro"
> option explicitly.

I believe we set up all the sections internally regardless of options,
just for simpler bookkeeping, and then emit only the ones we actually
want to produce.  Emitting an essentially empty .debug_macinfo section
with -fno-debug-macro would be a bug.
--paulr

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

Re: [llvm-dev] DebugInfo work contribution and update.

Kristof Beyls via cfe-dev
Yeah, there are a few places/times/situation where LLVM's emitted empty DWARF sections - minor bug imho. (yes, a bug, but no one's highest priority/pretty benign in the grand scheme of things - certainly if anyone wants to clean them up, that's great, makes reading dumps easier, etc)

On Fri, Oct 18, 2019 at 6:22 AM Robinson, Paul <[hidden email]> wrote:
> One query regarding clang behavior for debug_macinfo section -- Now, I
> understand that to enable macro information and for gdb able to expand
> macros, clang needs "-fdebug-macro". Default is not to emit debug info
> for macros.
>
> But consider below dump, is this Okay to have a empty{Size 1 byte}
> debug_macinfo section to be emitted ?? when we are not emitting macro
> info at all. 
> Should we stop emitting this ?? this is on purpose.
> Note: this behavior persists, even when specifying "-fno-debug-macro"
> option explicitly.

I believe we set up all the sections internally regardless of options,
just for simpler bookkeeping, and then emit only the ones we actually
want to produce.  Emitting an essentially empty .debug_macinfo section
with -fno-debug-macro would be a bug.
--paulr


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