BoF DWARF5 patches

BoF DWARF5 patches

[Mark Wielaard]

Hi,

This afternoon there will be a BoF at the virtual Cauldron about
DWARF5 and beyond. https://linuxplumbersconf.org/event/7/contributions/746/

Here are some patches for GCC that I would like to discuss.
I'll reply to them after the BoF with any comments people made.

Cheers,

Mark

[PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.

[Mark Wielaard]

DWARF5 makes it possible to read loclists tables without consulting
the debuginfo tree by introducing a table header. Adding location views
breaks this (at least for binutils and elfutils). So don't enable
variable-location-views by default if DWARF5 or higher is selected.
---
 gcc/doc/invoke.texi | 6 +++---
 gcc/toplev.c        | 1 +
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 70dc1ab73a12..e5dddc236d7d 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9301,9 +9301,9 @@ can be consumed by debug information consumers that are not aware of
 these augmentations, but they won't derive any benefit from them either.
 
 This is enabled by default when outputting DWARF 2 debug information at
-the normal level, as long as there is assembler support,
-@option{-fvar-tracking-assignments} is enabled and
-@option{-gstrict-dwarf} is not.  When assembler support is not
+the normal level for DWARF versions lower than 5, as long as there
+is assembler support, @option{-fvar-tracking-assignments} is enabled
+and @option{-gstrict-dwarf} is not.  When assembler support is not
 available, this may still be enabled, but it will force GCC to output
 internal line number tables, and if
 @option{-ginternal-reset-location-views} is not enabled, that will most
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 07457d08c3aa..34218c6b3349 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1672,6 +1672,7 @@ process_options (void)
 	   && (write_symbols == DWARF2_DEBUG
 	       || write_symbols == VMS_AND_DWARF2_DEBUG)
 	   && !dwarf_strict
+	   && dwarf_version < 5
 	   && dwarf2out_as_loc_support
 	   && dwarf2out_as_locview_support);
     }
-- 
2.18.4

Re: [PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.

[Jakub Jelinek]

On Mon, Aug 24, 2020 at 02:56:54PM +0200, Mark Wielaard wrote:
> DWARF5 makes it possible to read loclists tables without consulting
> the debuginfo tree by introducing a table header. Adding location views
> breaks this (at least for binutils and elfutils). So don't enable
> variable-location-views by default if DWARF5 or higher is selected.

This should be discussed with Alex, CCed.
I'd say elfutils/binutils should just show .debug_loclists independent of
.debug_info if there are no loc views and use .debug_info otherwise.

> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 70dc1ab73a12..e5dddc236d7d 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -9301,9 +9301,9 @@ can be consumed by debug information consumers that are not aware of
>  these augmentations, but they won't derive any benefit from them either.
>  
>  This is enabled by default when outputting DWARF 2 debug information at
> -the normal level, as long as there is assembler support,
> -@option{-fvar-tracking-assignments} is enabled and
> -@option{-gstrict-dwarf} is not.  When assembler support is not
> +the normal level for DWARF versions lower than 5, as long as there
> +is assembler support, @option{-fvar-tracking-assignments} is enabled
> +and @option{-gstrict-dwarf} is not.  When assembler support is not
>  available, this may still be enabled, but it will force GCC to output
>  internal line number tables, and if
>  @option{-ginternal-reset-location-views} is not enabled, that will most
> diff --git a/gcc/toplev.c b/gcc/toplev.c
> index 07457d08c3aa..34218c6b3349 100644
> --- a/gcc/toplev.c
> +++ b/gcc/toplev.c
> @@ -1672,6 +1672,7 @@ process_options (void)
>  	   && (write_symbols == DWARF2_DEBUG
>  	       || write_symbols == VMS_AND_DWARF2_DEBUG)
>  	   && !dwarf_strict
> +	   && dwarf_version < 5
>  	   && dwarf2out_as_loc_support
>  	   && dwarf2out_as_locview_support);
>      }
> -- 
> 2.18.4

	Jakub

Re: [PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.

[Mark Wielaard]

Hi,

On Mon, Aug 24, 2020 at 07:38:10PM +0200, Jakub Jelinek wrote:
> On Mon, Aug 24, 2020 at 02:56:54PM +0200, Mark Wielaard wrote:
> > DWARF5 makes it possible to read loclists tables without consulting
> > the debuginfo tree by introducing a table header. Adding location views
> > breaks this (at least for binutils and elfutils). So don't enable
> > variable-location-views by default if DWARF5 or higher is selected.
> 
> This should be discussed with Alex, CCed.
> I'd say elfutils/binutils should just show .debug_loclists independent of
> .debug_info if there are no loc views and use .debug_info otherwise.

Yes, sorry, should have CCed Alex. I do agree this is less than
ideal. It was really just to make sure the elfutils testsuite was
clean.

But the issue is real. As is, when enabling DWARF5, it is impossible
for consumers to parse the .debug_loclists independently. The only way
to know whether (and where) the locviews are is by finding and then
parsing the corresponding CU DIE tree.

There is actually an alternative representation enabled by
-gvariable-location-views=incompat5 that might help, but as the name
implies it isn't standard DWARF5, and I believe neither elfutils nor
binutils parses it.

I am not sure what a good default is in case we enable -gdwarf-5.

Cheers,

Mark

Re: [PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.

[Alexandre Oliva]

On Aug 24, 2020, Jakub Jelinek <jakub@redhat.com> wrote:

> On Mon, Aug 24, 2020 at 02:56:54PM +0200, Mark Wielaard wrote:
>> DWARF5 makes it possible to read loclists tables without consulting
>> the debuginfo tree by introducing a table header. Adding location views
>> breaks this (at least for binutils and elfutils). So don't enable
>> variable-location-views by default if DWARF5 or higher is selected.

> This should be discussed with Alex, CCed.
> I'd say elfutils/binutils should just show .debug_loclists independent of
> .debug_info if there are no loc views and use .debug_info otherwise.

I've suggested before that it made sense to me to start emitting
locviews when there were concrete plans to implement support for them in
debug info consumers.

Without such plans, it would make more sense to just disable them
altogether.

Now, if there are any such plans, it is disabling them for the default
debug format that doesn't make much sense to me; it would seem to make
more sense to adopt and promote the proposed extension, implemented in
=incompat5 in GCC, but it would need some implementation work in
consumers to at least ignore the extension.


Red Hat has had me involved in these efforts for over a decade, but I'm
not aware of its plans any more, and I don't know of anyone else driving
the implementation of locviews in consumers, so, given the little I
know, this patch seems like a timid step in a reasonable direction:
outputting locviews is no use if there are no consumers for it, more so
when they actively disturb existing standard-compliant consumers.

-- 
Alexandre Oliva, happy hacker
https://FSFLA.org/blogs/lxo/
Free Software Activist
GNU Toolchain Engineer

Re: [PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.

[Richard Biener]

On Tue, Aug 25, 2020 at 6:05 AM Alexandre Oliva <oliva@adacore.com> wrote:
>
> On Aug 24, 2020, Jakub Jelinek <jakub@redhat.com> wrote:
>
> > On Mon, Aug 24, 2020 at 02:56:54PM +0200, Mark Wielaard wrote:
> >> DWARF5 makes it possible to read loclists tables without consulting
> >> the debuginfo tree by introducing a table header. Adding location views
> >> breaks this (at least for binutils and elfutils). So don't enable
> >> variable-location-views by default if DWARF5 or higher is selected.
>
> > This should be discussed with Alex, CCed.
> > I'd say elfutils/binutils should just show .debug_loclists independent of
> > .debug_info if there are no loc views and use .debug_info otherwise.
>
> I've suggested before that it made sense to me to start emitting
> locviews when there were concrete plans to implement support for them in
> debug info consumers.
>
> Without such plans, it would make more sense to just disable them
> altogether.
>
> Now, if there are any such plans, it is disabling them for the default
> debug format that doesn't make much sense to me; it would seem to make
> more sense to adopt and promote the proposed extension, implemented in
> =incompat5 in GCC, but it would need some implementation work in
> consumers to at least ignore the extension.
>
>
> Red Hat has had me involved in these efforts for over a decade, but I'm
> not aware of its plans any more, and I don't know of anyone else driving
> the implementation of locviews in consumers, so, given the little I
> know, this patch seems like a timid step in a reasonable direction:
> outputting locviews is no use if there are no consumers for it, more so
> when they actively disturb existing standard-compliant consumers.

But then leaving it enabled by default but not with -gdwarf-5 looks odd
and backward to me as well.  If the consensus is there's no use then
please disable them by default everywhere instead.

Richard.

> --
> Alexandre Oliva, happy hacker
> https://FSFLA.org/blogs/lxo/
> Free Software Activist
> GNU Toolchain Engineer

Re: [PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.

[Mark Wielaard]

Hi Alex,

On Tue, 2020-08-25 at 01:05 -0300, Alexandre Oliva wrote:
> it would seem to
> make more sense to adopt and promote the proposed extension,
> implemented in =incompat5 in GCC, but it would need some
> implementation work in consumers to at least ignore the extension.

Is that what is described in:
http://www.fsfla.org/~lxoliva/papers/sfn/dwarf6-sfn-lvu.txt

Does it match the proposal in:
http://www.dwarfstd.org/ShowIssue.php?issue=170427.1

Should we try to introduce your extending loclists proposal:
http://www.dwarfstd.org/ShowIssue.php?issue=170427.2

The main issue is that there is no formal way of extending the
loclists.

Thanks,

Mark

Re: [PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.

[Alexandre Oliva]

Hello, Mark,

On Aug 25, 2020, Mark Wielaard <mark@klomp.org> wrote:

> On Tue, 2020-08-25 at 01:05 -0300, Alexandre Oliva wrote:
>> it would seem to
>> make more sense to adopt and promote the proposed extension,
>> implemented in =incompat5 in GCC, but it would need some
>> implementation work in consumers to at least ignore the extension.

> Is that what is described in:
> http://www.fsfla.org/~lxoliva/papers/sfn/dwarf6-sfn-lvu.txt

> Does it match the proposal in:
> http://www.dwarfstd.org/ShowIssue.php?issue=170427.1

Yes, the implementation of incompat5 is supposed to match the
enhancement to DWARF proposed in this issue.

> Should we try to introduce your extending loclists proposal:
> http://www.dwarfstd.org/ShowIssue.php?issue=170427.2

If it makes sense to you, sure.  I think it could be useful for loclist
compression, besides adding extensibility to an unusually rigid part of
DWARF specs.  I'm not attached to this particular formulation, though,
and I'm not aware of any implementations thereof.  I only felt the need
for extending loclists and found myself severely constrained.

> The main issue is that there is no formal way of extending the
> loclists.

*nod*

Thanks,

-- 
Alexandre Oliva, happy hacker
https://FSFLA.org/blogs/lxo/
Free Software Activist
GNU Toolchain Engineer

Re: [PATCH 1/5] Don't enable -gvariable-location-views by default for DWARF5.

[Mark Wielaard]

Hi,

On Mon, 2020-08-24 at 19:38 +0200, Jakub Jelinek wrote:
> On Mon, Aug 24, 2020 at 02:56:54PM +0200, Mark Wielaard wrote:
> > DWARF5 makes it possible to read loclists tables without consulting
> > the debuginfo tree by introducing a table header. Adding location
> > views
> > breaks this (at least for binutils and elfutils). So don't enable
> > variable-location-views by default if DWARF5 or higher is selected.
> 
> This should be discussed with Alex, CCed.
> I'd say elfutils/binutils should just show .debug_loclists
> independent of
> .debug_info if there are no loc views and use .debug_info otherwise.

So it turned out that it was really bugs in elfutils and binutils.
For elfutils it now tracks locviews in .debug_loclists just like it did
for .debug_loc:
https://sourceware.org/pipermail/elfutils-devel/2020q3/002900.html

For binutils it actually tracked locviews correctly, but didn't handle
DW_LLE_start_end and DW_LLE_start_length. Patch submitted:
https://sourceware.org/pipermail/binutils/2020-September/113510.html

For tools that access the location lists (and locviews) through the DIE
attributes this never was an issue.

Patch retracted.

Cheers,

Mark

[PATCH 2/5] Make sure that static data member constexpr isn't optimized away in test.

[Mark Wielaard]

In DWARF5 class variables (static data members) are represented with a
DW_TAG_variable instead of a DW_TAG_member. Make sure the variable isn't
optimized away in the constexpr-var-1.C testcase so we can still match (2)
const_expr in the the assembly output.

Note that the same issue causes some failures in the gdb testsuite
for static data members when we enable DWARF5 by default:
https://sourceware.org/bugzilla/show_bug.cgi?id=26525
---
 gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C b/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C
index 19062e29fd59..c6ad3f645379 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C
@@ -7,3 +7,4 @@ struct S
 {
   static constexpr int b = 6;
 } s;
+const int &c = s.b;
-- 
2.18.4

Re: [PATCH 2/5] Make sure that static data member constexpr isn't optimized away in test.

[Jakub Jelinek]

On Mon, Aug 24, 2020 at 02:56:55PM +0200, Mark Wielaard wrote:
> In DWARF5 class variables (static data members) are represented with a
> DW_TAG_variable instead of a DW_TAG_member. Make sure the variable isn't
> optimized away in the constexpr-var-1.C testcase so we can still match (2)
> const_expr in the the assembly output.
> 
> Note that the same issue causes some failures in the gdb testsuite
> for static data members when we enable DWARF5 by default:
> https://sourceware.org/bugzilla/show_bug.cgi?id=26525
> ---
>  gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C b/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C
> index 19062e29fd59..c6ad3f645379 100644
> --- a/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C
> +++ b/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C
> @@ -7,3 +7,4 @@ struct S
>  {
>    static constexpr int b = 6;
>  } s;
> +const int &c = s.b;

This looks incorrect to me, that is a workaround for a real GCC bug.

Shouldn't we instead do something like (untested) following patch?
I mean, for DWARF < 5 the static data members were using DW_TAG_member,
which has been always marked by the function, so IMHO we should also always
mark the DW_TAG_variables at the class scope that replaced those.

2020-08-24  Jakub Jelinek  <jakub@redhat.com>

	* dwarf2out.c (prune_unused_types_walk): Mark DW_TAG_variable DIEs
	at class scope for DWARF5+.

--- gcc/dwarf2out.c.jj	2020-07-28 15:39:09.883757946 +0200
+++ gcc/dwarf2out.c	2020-08-24 19:33:16.503961786 +0200
@@ -29392,6 +29392,13 @@ prune_unused_types_walk (dw_die_ref die)
 	  if (die->die_perennial_p)
 	    break;
 
+	  /* For static data members, the declaration in the class is supposed
+	     to have DW_TAG_member tag in DWARF{3,4} but DW_TAG_variable in
+	     DWARF5.  DW_TAG_member will be marked, so mark even such
+	     DW_TAG_variables in DWARF5.  */
+	  if (dwarf_version >= 5 && class_scope_p (die->die_parent))
+	    break;
+
 	  /* premark_used_variables marks external variables --- don't mark
 	     them here.  But function-local externals are always considered
 	     used.  */


	Jakub

Re: [PATCH 2/5] Make sure that static data member constexpr isn't optimized away in test.

[Mark Wielaard]

Hi Jakub,

On Mon, Aug 24, 2020 at 07:40:51PM +0200, Jakub Jelinek wrote:
> On Mon, Aug 24, 2020 at 02:56:55PM +0200, Mark Wielaard wrote:
> > In DWARF5 class variables (static data members) are represented with a
> > DW_TAG_variable instead of a DW_TAG_member. Make sure the variable isn't
> > optimized away in the constexpr-var-1.C testcase so we can still match (2)
> > const_expr in the the assembly output.
> > 
> > Note that the same issue causes some failures in the gdb testsuite
> > for static data members when we enable DWARF5 by default:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=26525
> > ---
> >  gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C b/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C
> > index 19062e29fd59..c6ad3f645379 100644
> > --- a/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C
> > +++ b/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C
> > @@ -7,3 +7,4 @@ struct S
> >  {
> >    static constexpr int b = 6;
> >  } s;
> > +const int &c = s.b;
> 
> This looks incorrect to me, that is a workaround for a real GCC bug.

I was discussing this after the BoF with Tom Tromey (CCed) and he also
thought gdb could/should actually support the DWARF5 representation,
but because the DW_TAG_variable was removed because the static data
member wasn't referenced in the gdb testcases.

> Shouldn't we instead do something like (untested) following patch?
> I mean, for DWARF < 5 the static data members were using DW_TAG_member,
> which has been always marked by the function, so IMHO we should also always
> mark the DW_TAG_variables at the class scope that replaced those.
> 
> 2020-08-24  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* dwarf2out.c (prune_unused_types_walk): Mark DW_TAG_variable DIEs
> 	at class scope for DWARF5+.

This looks really good, and it makes all the FAILs in the gdb bug
report PASS (when build with -gdwarf-5 as default).

> --- gcc/dwarf2out.c.jj	2020-07-28 15:39:09.883757946 +0200
> +++ gcc/dwarf2out.c	2020-08-24 19:33:16.503961786 +0200
> @@ -29392,6 +29392,13 @@ prune_unused_types_walk (dw_die_ref die)
>  	  if (die->die_perennial_p)
>  	    break;
>  
> +	  /* For static data members, the declaration in the class is supposed
> +	     to have DW_TAG_member tag in DWARF{3,4} but DW_TAG_variable in
> +	     DWARF5.  DW_TAG_member will be marked, so mark even such
> +	     DW_TAG_variables in DWARF5.  */
> +	  if (dwarf_version >= 5 && class_scope_p (die->die_parent))
> +	    break;
> +
>  	  /* premark_used_variables marks external variables --- don't mark
>  	     them here.  But function-local externals are always considered
>  	     used.  */

Thanks,

Mark

Re: [PATCH 2/5] Make sure that static data member constexpr isn't optimized away in test.

[Tom Tromey]

>> This looks incorrect to me, that is a workaround for a real GCC bug.

Mark> I was discussing this after the BoF with Tom Tromey (CCed) and he also
Mark> thought gdb could/should actually support the DWARF5 representation,
Mark> but because the DW_TAG_variable was removed because the static data
Mark> member wasn't referenced in the gdb testcases.

I updated the gdb bug with some findings:

https://sourceware.org/bugzilla/show_bug.cgi?id=26525

Mark> This looks really good, and it makes all the FAILs in the gdb bug
Mark> report PASS (when build with -gdwarf-5 as default).

I thought this might be the case; thank you for trying it out.

Tom

Re: [PATCH 2/5] Make sure that static data member constexpr isn't optimized away in test.

[Jason Merrill]

On 8/24/20 1:40 PM, Jakub Jelinek wrote:
> On Mon, Aug 24, 2020 at 02:56:55PM +0200, Mark Wielaard wrote:
>> In DWARF5 class variables (static data members) are represented with a
>> DW_TAG_variable instead of a DW_TAG_member. Make sure the variable isn't
>> optimized away in the constexpr-var-1.C testcase so we can still match (2)
>> const_expr in the the assembly output.
>>
>> Note that the same issue causes some failures in the gdb testsuite
>> for static data members when we enable DWARF5 by default:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=26525
>> ---
>>   gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C b/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C
>> index 19062e29fd59..c6ad3f645379 100644
>> --- a/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C
>> +++ b/gcc/testsuite/g++.dg/debug/dwarf2/constexpr-var-1.C
>> @@ -7,3 +7,4 @@ struct S
>>   {
>>     static constexpr int b = 6;
>>   } s;
>> +const int &c = s.b;
> 
> This looks incorrect to me, that is a workaround for a real GCC bug.
> 
> Shouldn't we instead do something like (untested) following patch?
> I mean, for DWARF < 5 the static data members were using DW_TAG_member,
> which has been always marked by the function, so IMHO we should also always
> mark the DW_TAG_variables at the class scope that replaced those.

The earlier behavior seems like an accident, that happened because we 
always need to emit information about non-static data members.  I don't 
think we should take it as guidance.

In this case one reason we don't emit debug info is because (before 
C++17) there's no definition of 'b'.  After C++17 the in-class 
declaration of 'b' is a definition, but we don't have to give it a 
symbol, so there's still nothing for the debug info to describe.

This issue doesn't seem specific to class members; it also affects 
namespace-scope C++17 inline variables:

inline const int var = 42;
int main() { return var; }

Compiling this testcase with -g doesn't emit any debug info for 'var' 
even though it's used.

Should we assume that if a variable with DW_AT_const_value is TREE_USED, 
we need to write out debug info for it?

Jason


> 2020-08-24  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* dwarf2out.c (prune_unused_types_walk): Mark DW_TAG_variable DIEs
> 	at class scope for DWARF5+.
> 
> --- gcc/dwarf2out.c.jj	2020-07-28 15:39:09.883757946 +0200
> +++ gcc/dwarf2out.c	2020-08-24 19:33:16.503961786 +0200
> @@ -29392,6 +29392,13 @@ prune_unused_types_walk (dw_die_ref die)
>   	  if (die->die_perennial_p)
>   	    break;
>   
> +	  /* For static data members, the declaration in the class is supposed
> +	     to have DW_TAG_member tag in DWARF{3,4} but DW_TAG_variable in
> +	     DWARF5.  DW_TAG_member will be marked, so mark even such
> +	     DW_TAG_variables in DWARF5.  */
> +	  if (dwarf_version >= 5 && class_scope_p (die->die_parent))
> +	    break;
> +
>   	  /* premark_used_variables marks external variables --- don't mark
>   	     them here.  But function-local externals are always considered
>   	     used.  */
> 
> 
> 	Jakub
> 

Re: [PATCH 2/5] Make sure that static data member constexpr isn't optimized away in test.

[Mark Wielaard]

Hi,

On Mon, 2020-08-24 at 17:38 -0400, Jason Merrill wrote:
> > This looks incorrect to me, that is a workaround for a real GCC bug.
> > 
> > Shouldn't we instead do something like (untested) following patch?
> > I mean, for DWARF < 5 the static data members were using DW_TAG_member,
> > which has been always marked by the function, so IMHO we should also always
> > mark the DW_TAG_variables at the class scope that replaced those.
> 
> The earlier behavior seems like an accident, that happened because we 
> always need to emit information about non-static data members.  I don't 
> think we should take it as guidance.

Maybe the reason they got emitted this way was an accident on the GCC
side. But I don't think it is an accident on the GDB side. At least
looking at the various gdb testcases, the intention is to show a
struct/class type as defined to the user, which includes both the
static and non-static data members of a class.

> In this case one reason we don't emit debug info is because (before 
> C++17) there's no definition of 'b'.  After C++17 the in-class 
> declaration of 'b' is a definition, but we don't have to give it a 
> symbol, so there's still nothing for the debug info to describe.

But don't we describe other parts of a type that don't have a symbol as
part of the debug info?

> This issue doesn't seem specific to class members; it also affects 
> namespace-scope C++17 inline variables:
> 
> inline const int var = 42;
> int main() { return var; }
> 
> Compiling this testcase with -g doesn't emit any debug info for 'var' 
> even though it's used.

That is new in GCC11, don't have GCC10 here to compare against, but
GCC9 produces:

DWARF section [27] '.debug_info' at offset 0x30b5:
 [Offset]
 Compilation unit at offset 0:
 Version: 5, Abbreviation section offset: 0, Address size: 8, Offset size: 4
 Unit type: compile (1)
 [     c]  compile_unit         abbrev: 1
           producer             (strp) "GNU C++17 9.3.1 20200408 (Red Hat 9.3.1-2) -mtune=generic -march=x86-64 -gdwarf-5 -O2 -std=gnu++17"
           language             (data1) C_plus_plus_14 (33)
           name                 (strp) "p.cc"
           comp_dir             (strp) "/tmp"
           ranges               (sec_offset) range list [     c]
           low_pc               (addr) 000000000000000000
           stmt_list            (sec_offset) 0
 [    2a]    variable             abbrev: 2
             name                 (string) "var"
             decl_file            (data1) p.cc (1)
             decl_line            (data1) 1
             decl_column          (data1) 18
             type                 (ref4) [    3f]
             external             (flag_present) yes
             inline               (data1) declared_inlined (3)
             const_value          (data1) 42
 [    38]    base_type            abbrev: 3
             byte_size            (data1) 4
             encoding             (data1) signed (5)
             name                 (string) "int"
 [    3f]    const_type           abbrev: 4
             type                 (ref4) [    38]
 [    44]    subprogram           abbrev: 5
             external             (flag_present) yes
             name                 (strp) "main"
             decl_file            (data1) p.cc (1)
             decl_line            (data1) 2
             decl_column          (data1) 5
             type                 (ref4) [    38]
             low_pc               (addr) 0x0000000000401050 <main>
             high_pc              (data8) 6 (0x0000000000401056 <_start>)
             frame_base           (exprloc) 
              [ 0] call_frame_cfa
             call_all_calls       (flag_present) yes

> Should we assume that if a variable with DW_AT_const_value is TREE_USED, 
> we need to write out debug info for it?

I would say yes. If it is used a user might want to look up its value.

Cheers,

Mark

Re: [PATCH 2/5] Make sure that static data member constexpr isn't optimized away in test.

[Jason Merrill]

On 8/25/20 5:19 AM, Mark Wielaard wrote:
> On Mon, 2020-08-24 at 17:38 -0400, Jason Merrill wrote:
>>> This looks incorrect to me, that is a workaround for a real GCC bug.
>>>
>>> Shouldn't we instead do something like (untested) following patch?
>>> I mean, for DWARF < 5 the static data members were using DW_TAG_member,
>>> which has been always marked by the function, so IMHO we should also always
>>> mark the DW_TAG_variables at the class scope that replaced those.
>>
>> The earlier behavior seems like an accident, that happened because we
>> always need to emit information about non-static data members.  I don't
>> think we should take it as guidance.
> 
> Maybe the reason they got emitted this way was an accident on the GCC
> side. But I don't think it is an accident on the GDB side. At least
> looking at the various gdb testcases, the intention is to show a
> struct/class type as defined to the user, which includes both the
> static and non-static data members of a class.

That would make sense.

>> In this case one reason we don't emit debug info is because (before
>> C++17) there's no definition of 'b'.  After C++17 the in-class
>> declaration of 'b' is a definition, but we don't have to give it a
>> symbol, so there's still nothing for the debug info to describe.
> 
> But don't we describe other parts of a type that don't have a symbol as
> part of the debug info?

It seems that currently we describe unused/undefined functions, but not 
unused nested types/typedefs.

On 8/25/20 8:41 AM, Jakub Jelinek wrote:
> 
> On Mon, Aug 24, 2020 at 05:38:28PM -0400, Jason Merrill via Gcc-patches wrote:
>>
>> This issue doesn't seem specific to class members; it also affects
>> namespace-scope C++17 inline variables:
>>
>> inline const int var = 42;
>> int main() { return var; }
>>
>> Compiling this testcase with -g doesn't emit any debug info for 'var' even
>> though it's used.
>>
>> Should we assume that if a variable with DW_AT_const_value is TREE_USED, we
>> need to write out debug info for it?
> 
> I guess it is a question of how exactly the (default on)
> -feliminate-unused-debug-symbols should behave with different kind of
> entities.
> 
> One thing are the non-inline static data members without const/constexpr or
> without initializer in the class.  Those need a definition if they are ever
> used, so it is probably fine to only emit them in the class in the TU where
> they are defined.  But note that e.g. with -fdebug-types-section we still
> force them to be output in class and do no pruning (and the pruning actually
> makes dwz less efficient unless dwz is tought to not only merge the DIEs
> with the same children and attributes, but also reconstruct more complete
> DIEs out of several less complete ones for the same class).

Right, this gets at Mark's point above.  How much pruning do we want to 
do of class bodies?  We currently do some, but how much benefit does 
that actually give us?  Is it worth the cost?

> Another case is non-inline static const data member with initializer,
> do we track non-odr uses e.g. during constant evaluation and if so, should
> that result in the static data member appearing?  Because if the static
> const data member with initializer is never odr used, it doesn't have to be
> ever defined and so it might never appear in the debug info.
> 
> Another case are inline vars, shall we treat as being used just that they
> were used in some constant expression, or do only odr uses count?

If the goal of debug info is to be able to evaluate the same expressions 
that appear in the source, constant uses need to count, too.  I wonder 
how we could associate the uses with their context so pruning works 
properly.

Jason

Re: [PATCH 2/5] Make sure that static data member constexpr isn't optimized away in test.

[Jason Merrill]

On 9/1/20 2:46 PM, Jason Merrill wrote:
> On 8/25/20 5:19 AM, Mark Wielaard wrote:
>> On Mon, 2020-08-24 at 17:38 -0400, Jason Merrill wrote:
>>>> This looks incorrect to me, that is a workaround for a real GCC bug.
>>>>
>>>> Shouldn't we instead do something like (untested) following patch?
>>>> I mean, for DWARF < 5 the static data members were using DW_TAG_member,
>>>> which has been always marked by the function, so IMHO we should also 
>>>> always
>>>> mark the DW_TAG_variables at the class scope that replaced those.
>>>
>>> The earlier behavior seems like an accident, that happened because we
>>> always need to emit information about non-static data members.  I don't
>>> think we should take it as guidance.
>>
>> Maybe the reason they got emitted this way was an accident on the GCC
>> side. But I don't think it is an accident on the GDB side. At least
>> looking at the various gdb testcases, the intention is to show a
>> struct/class type as defined to the user, which includes both the
>> static and non-static data members of a class.
> 
> That would make sense.

So, GDB prefers no pruning of members...

>>> In this case one reason we don't emit debug info is because (before
>>> C++17) there's no definition of 'b'.  After C++17 the in-class
>>> declaration of 'b' is a definition, but we don't have to give it a
>>> symbol, so there's still nothing for the debug info to describe.
>>
>> But don't we describe other parts of a type that don't have a symbol as
>> part of the debug info?
> 
> It seems that currently we describe unused/undefined functions, but not 
> unused nested types/typedefs.

> On 8/25/20 8:41 AM, Jakub Jelinek wrote:
>>
>> On Mon, Aug 24, 2020 at 05:38:28PM -0400, Jason Merrill via 
>> Gcc-patches wrote:
>>>
>>> This issue doesn't seem specific to class members; it also affects
>>> namespace-scope C++17 inline variables:
>>>
>>> inline const int var = 42;
>>> int main() { return var; }
>>>
>>> Compiling this testcase with -g doesn't emit any debug info for 'var' 
>>> even
>>> though it's used.
>>>
>>> Should we assume that if a variable with DW_AT_const_value is 
>>> TREE_USED, we
>>> need to write out debug info for it?
>>
>> I guess it is a question of how exactly the (default on)
>> -feliminate-unused-debug-symbols should behave with different kind of
>> entities.
>>
>> One thing are the non-inline static data members without const/constexpr or
>> without initializer in the class.  Those need a definition if they are ever
>> used, so it is probably fine to only emit them in the class in the TU where
>> they are defined.  But note that e.g. with -fdebug-types-section we still
>> force them to be output in class and do no pruning (and the pruning actually
>> makes dwz less efficient unless dwz is tought to not only merge the DIEs
>> with the same children and attributes, but also reconstruct more complete
>> DIEs out of several less complete ones for the same class).
> 
> Right, this gets at Mark's point above.  How much pruning do we want to 
> do of class bodies?  We currently do some, but how much benefit does 
> that actually give us?  Is it worth the cost?

...and our deduplication mechanisms prefer no pruning of members.

>> Another case is non-inline static const data member with initializer,
>> do we track non-odr uses e.g. during constant evaluation and if so, should
>> that result in the static data member appearing?  Because if the static
>> const data member with initializer is never odr used, it doesn't have to be
>> ever defined and so it might never appear in the debug info.
>>
>> Another case are inline vars, shall we treat as being used just that they
>> were used in some constant expression, or do only odr uses count?
> 
> If the goal of debug info is to be able to evaluate the same expressions 
> that appear in the source, constant uses need to count, too.  I wonder 
> how we could associate the uses with their context so pruning works 
> properly.

For GCC 11, I think let's fix the regression with your (Jakub) earlier 
patch, maybe only for DIEs with DW_AT_const_value.

For GCC 12, maybe we want to stop pruning any class members by default.

Jason

Re: [PATCH 2/5] Make sure that static data member constexpr isn't optimized away in test.

[Jakub Jelinek]

On Tue, Feb 09, 2021 at 02:40:12PM -0500, Jason Merrill wrote:
> For GCC 11, I think let's fix the regression with your (Jakub) earlier
> patch, maybe only for DIEs with DW_AT_const_value.

Thanks.
Following works too, so I'll test it tonight.

2021-02-09  Jakub Jelinek  <jakub@redhat.com>

	PR debug/98755
	* dwarf2out.c (prune_unused_types_walk): Mark DW_TAG_variable DIEs
	at class scope for DWARF5+.

--- gcc/dwarf2out.c.jj	2021-01-27 10:05:35.313942040 +0100
+++ gcc/dwarf2out.c	2021-02-09 20:51:42.907922550 +0100
@@ -29475,6 +29475,16 @@ prune_unused_types_walk (dw_die_ref die)
 	  if (die->die_perennial_p)
 	    break;
 
+	  /* For static data members, the declaration in the class is supposed
+	     to have DW_TAG_member tag in DWARF{3,4} but DW_TAG_variable in
+	     DWARF5.  DW_TAG_member will be marked, so mark even such
+	     DW_TAG_variables in DWARF5, as long as it has DW_AT_const_value
+	     attribute.  */
+	  if (dwarf_version >= 5
+	      && class_scope_p (die->die_parent)
+	      && get_AT (die, DW_AT_const_value))
+	    break;
+
 	  /* premark_used_variables marks external variables --- don't mark
 	     them here.  But function-local externals are always considered
 	     used.  */


	Jakub

Re: [PATCH 2/5] Make sure that static data member constexpr isn't optimized away in test.

[Jakub Jelinek]

On Tue, Feb 09, 2021 at 08:55:26PM +0100, Jakub Jelinek wrote:
> On Tue, Feb 09, 2021 at 02:40:12PM -0500, Jason Merrill wrote:
> > For GCC 11, I think let's fix the regression with your (Jakub) earlier
> > patch, maybe only for DIEs with DW_AT_const_value.
> 
> Thanks.
> Following works too, so I'll test it tonight.

The patch fixed not just the expected
-FAIL: g++.dg/debug/dwarf2/constexpr-var-1.C   scan-assembler-times  DW_AT_const_expr 2
but also
-FAIL: libstdc++-prettyprinters/80276.cc whatis p4
-FAIL: libstdc++-prettyprinters/80276.cc whatis p4
-FAIL: libstdc++-prettyprinters/libfundts.cc print as
-FAIL: libstdc++-prettyprinters/libfundts.cc print as
-FAIL: libstdc++-prettyprinters/libfundts.cc print os
-FAIL: libstdc++-prettyprinters/libfundts.cc print os

	Jakub

Re: [PATCH 2/5] Make sure that static data member constexpr isn't optimized away in test.

[Jakub Jelinek]

On Mon, Aug 24, 2020 at 05:38:28PM -0400, Jason Merrill via Gcc-patches wrote:
> > Shouldn't we instead do something like (untested) following patch?
> > I mean, for DWARF < 5 the static data members were using DW_TAG_member,
> > which has been always marked by the function, so IMHO we should also always
> > mark the DW_TAG_variables at the class scope that replaced those.
> 
> The earlier behavior seems like an accident, that happened because we always
> need to emit information about non-static data members.  I don't think we
> should take it as guidance.
> 
> In this case one reason we don't emit debug info is because (before C++17)
> there's no definition of 'b'.  After C++17 the in-class declaration of 'b'
> is a definition, but we don't have to give it a symbol, so there's still
> nothing for the debug info to describe.
> 
> This issue doesn't seem specific to class members; it also affects
> namespace-scope C++17 inline variables:
> 
> inline const int var = 42;
> int main() { return var; }
> 
> Compiling this testcase with -g doesn't emit any debug info for 'var' even
> though it's used.
> 
> Should we assume that if a variable with DW_AT_const_value is TREE_USED, we
> need to write out debug info for it?

I guess it is a question of how exactly the (default on)
-feliminate-unused-debug-symbols should behave with different kind of
entities.

One thing are the non-inline static data members without const/constexpr or
without initializer in the class.  Those need a definition if they are ever
used, so it is probably fine to only emit them in the class in the TU where
they are defined.  But note that e.g. with -fdebug-types-section we still
force them to be output in class and do no pruning (and the pruning actually
makes dwz less efficient unless dwz is tought to not only merge the DIEs
with the same children and attributes, but also reconstruct more complete
DIEs out of several less complete ones for the same class).

Another case is non-inline static const data member with initializer,
do we track non-odr uses e.g. during constant evaluation and if so, should
that result in the static data member appearing?  Because if the static
const data member with initializer is never odr used, it doesn't have to be
ever defined and so it might never appear in the debug info.

Another case are inline vars, shall we treat as being used just that they
were used in some constant expression, or do only odr uses count?

And, shall we make the DWARF-3/4 DW_TAG_member in class behave the same as
DW_TAG_variable in DWARF-5?

	Jakub

[PATCH 3/5] Add DWARF5 variants of assembly scan tests that use DW_FORM_implicit_const

[Mark Wielaard]

Some DWARF tests scan the assembly output looking for constant values.
When using DWARF5 those constants might use DW_FORM_implicit_const,
which are output (in the comments) after the attribute instead of
before. To make sure these tests work introduce a -gdwarf-5 variant
of these tests and explicitly use -gdwarf-2 for the original.
---
 .../dwarf2/{inline-var-1.C => inline-var-1-dwarf5.C}      | 6 ++++--
 gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C          | 2 +-
 .../gcc.dg/debug/dwarf2/{inline2.c => inline2-dwarf5.c}   | 7 ++++---
 gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c               | 4 +++-
 .../debug/dwarf2/{pr41445-5.c => pr41445-5-dwarf5.c}      | 8 ++++----
 gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c             | 2 +-
 .../debug/dwarf2/{pr41445-6.c => pr41445-6-dwarf5.c}      | 8 ++++----
 gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c             | 2 +-
 8 files changed, 22 insertions(+), 17 deletions(-)
 copy gcc/testsuite/g++.dg/debug/dwarf2/{inline-var-1.C => inline-var-1-dwarf5.C} (76%)
 copy gcc/testsuite/gcc.dg/debug/dwarf2/{inline2.c => inline2-dwarf5.c} (88%)
 copy gcc/testsuite/gcc.dg/debug/dwarf2/{pr41445-5.c => pr41445-5-dwarf5.c} (73%)
 copy gcc/testsuite/gcc.dg/debug/dwarf2/{pr41445-6.c => pr41445-6-dwarf5.c} (68%)

diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C b/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1-dwarf5.C
similarity index 76%
copy from gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
copy to gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1-dwarf5.C
index 3b1c913edfca..52ed5b6912fd 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1-dwarf5.C
@@ -1,7 +1,9 @@
+// DWARF5 variant of inline-var-1.C
 // { dg-do compile { target c++17 } }
-// { dg-options "-O -g -dA -gno-strict-dwarf -fno-eliminate-unused-debug-symbols" }
+// { dg-options "-O -gdwarf-5 -dA -gno-strict-dwarf -fno-eliminate-unused-debug-symbols" }
 // { dg-require-weak "" }
-// { dg-final { scan-assembler-times "0x3\[^\n\r]* DW_AT_inline" 6 { xfail *-*-aix* } } }
+// { dg-final { scan-assembler-times " DW_AT_inline \\(0x3\\)" 2 { xfail *-*-aix* } } }
+// { dg-final { scan-assembler-times "0x3\[^\n\r]* DW_AT_inline" 4 { xfail *-*-aix* } } }
 // { dg-final { scan-assembler-times "0x1\[^\n\r]* DW_AT_inline" 2 { xfail *-*-aix* } } }
 // { dg-final { scan-assembler-times " DW_AT_declaration" 6 { xfail *-*-aix* } } }
 // { dg-final { scan-assembler-times " DW_AT_specification" 6 { xfail *-*-aix* } } }
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C b/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
index 3b1c913edfca..9a88e28cbe0f 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
@@ -1,5 +1,5 @@
 // { dg-do compile { target c++17 } }
-// { dg-options "-O -g -dA -gno-strict-dwarf -fno-eliminate-unused-debug-symbols" }
+// { dg-options "-O -gdwarf-2 -dA -gno-strict-dwarf -fno-eliminate-unused-debug-symbols" }
 // { dg-require-weak "" }
 // { dg-final { scan-assembler-times "0x3\[^\n\r]* DW_AT_inline" 6 { xfail *-*-aix* } } }
 // { dg-final { scan-assembler-times "0x1\[^\n\r]* DW_AT_inline" 2 { xfail *-*-aix* } } }
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c b/gcc/testsuite/gcc.dg/debug/dwarf2/inline2-dwarf5.c
similarity index 88%
copy from gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
copy to gcc/testsuite/gcc.dg/debug/dwarf2/inline2-dwarf5.c
index 7e019a6c06a0..03013f11bca8 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline2-dwarf5.c
@@ -1,4 +1,4 @@
-/* Contributed by Dodji Seketeli <dodji@redhat.com>
+/* DWARF5 variant of inline2.
    Origin: PR debug/37801
 
   Abstract instances (DW_TAG_subroutines having the DW_AT_inline attribute)
@@ -14,7 +14,8 @@
   properly nested DW_TAG_inlined_subroutine DIEs for third, second and first.
 */
 
-/* { dg-options "-O -g3 -gdwarf -dA -fgnu89-inline" } */
+/* Explicitly use dwarf-5 which uses DW_FORM_implicit_const.  */
+/* { dg-options "-O -g3 -gdwarf-5 -dA -fgnu89-inline" } */
 /* { dg-do compile } */
 
 /* There are 6 inlined subroutines:
@@ -32,7 +33,7 @@
 /* There are 3 DW_AT_inline attributes: one per abstract inline instance.
    The value of the attribute must be 0x3, meaning the function was
    actually inlined.  */
-/* { dg-final { scan-assembler-times  "(?:byte|data1)\[^\n\]*0x3\[^\n\]* DW_AT_inline" 3 } } */
+/* { dg-final { scan-assembler-times  " DW_AT_inline \\(0x3\\)" 3 } } */
 
 volatile int *a;
 
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c b/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
index 7e019a6c06a0..9c36450ae2de 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
@@ -14,7 +14,9 @@
   properly nested DW_TAG_inlined_subroutine DIEs for third, second and first.
 */
 
-/* { dg-options "-O -g3 -gdwarf -dA -fgnu89-inline" } */
+/* Explicitly use dwarf-2 because dwarf-5 might use DW_FORM_implicit_const
+   which is hard to scan for. */
+/* { dg-options "-O -g3 -gdwarf-2 -dA -fgnu89-inline" } */
 /* { dg-do compile } */
 
 /* There are 6 inlined subroutines:
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5-dwarf5.c
similarity index 73%
copy from gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
copy to gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5-dwarf5.c
index d646f5983b30..0e0de822d806 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5-dwarf5.c
@@ -1,8 +1,8 @@
-/* PR preprocessor/41445 */
+/* PR preprocessor/41445 DWARF5 variant */
 /* Test that token after multi-line function-like macro use
    gets correct locus even when preprocessing separately.  */
 /* { dg-do compile } */
-/* { dg-options "-save-temps -gdwarf -O0 -dA -fno-merge-debug-strings" } */
+/* { dg-options "-save-temps -gdwarf-5 -O0 -dA -fno-merge-debug-strings" } */
 
 #define A(x) vari x
 #define vari(x)
@@ -12,5 +12,5 @@ int A(B) ;
 /*  We want to check that both vari and varj have the same line
     number.  */
 
-/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"vari\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^0-9a-fA-FxX](0xa|10)\[^0-9a-fA-FxX]\[^\\r\\n\]*DW_AT_decl_line" } } */
-/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"varj\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^0-9a-fA-FxX](0xa|10)\[^0-9a-fA-FxX]\[^\\r\\n\]*DW_AT_decl_line" } } */
+/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"vari\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^\\r\\n\]*DW_AT_decl_line \\((0xa|10)\\)" } } */
+/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"varj\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^\\r\\n\]*DW_AT_decl_line \\((0xa|10)\\)" } } */
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
index d646f5983b30..80300ec22e87 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
@@ -2,7 +2,7 @@
 /* Test that token after multi-line function-like macro use
    gets correct locus even when preprocessing separately.  */
 /* { dg-do compile } */
-/* { dg-options "-save-temps -gdwarf -O0 -dA -fno-merge-debug-strings" } */
+/* { dg-options "-save-temps -gdwarf-2 -O0 -dA -fno-merge-debug-strings" } */
 
 #define A(x) vari x
 #define vari(x)
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6-dwarf5.c
similarity index 68%
copy from gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
copy to gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6-dwarf5.c
index 340cb3835307..3a6eeb530968 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6-dwarf5.c
@@ -1,11 +1,11 @@
-/* PR preprocessor/41445 */
+/* PR preprocessor/41445 DWARF5 variant*/
 /* { dg-do compile } */
-/* { dg-options "-gdwarf -O0 -dA -fno-merge-debug-strings" } */
+/* { dg-options "-gdwarf-5 -O0 -dA -fno-merge-debug-strings" } */
 
 #include "pr41445-5.c"
 
 /*  We want to check that both vari and varj have the same line
     number.  */
 
-/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"vari\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^0-9a-fA-FxX](0xa|10)?\[^0-9a-fA-FxX]\[^\\r\\n\]*DW_AT_decl_line" } } */
-/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"varj\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^0-9a-fA-FxX](0xa|10)\[^0-9a-fA-FxX]\[^\\r\\n\]*DW_AT_decl_line" } } */
+/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"vari\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^\\r\\n\]*DW_AT_decl_line \\((0xa|10)\\)" } } */
+/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"varj\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^\\r\\n\]*DW_AT_decl_line \\((0xa|10)\\)" } } */
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
index 340cb3835307..fbf033758b6b 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
@@ -1,6 +1,6 @@
 /* PR preprocessor/41445 */
 /* { dg-do compile } */
-/* { dg-options "-gdwarf -O0 -dA -fno-merge-debug-strings" } */
+/* { dg-options "-gdwarf-2 -O0 -dA -fno-merge-debug-strings" } */
 
 #include "pr41445-5.c"
 
-- 
2.18.4

Re: [PATCH 3/5] Add DWARF5 variants of assembly scan tests that use DW_FORM_implicit_const

[Jakub Jelinek]

On Mon, Aug 24, 2020 at 02:56:56PM +0200, Mark Wielaard wrote:
> Some DWARF tests scan the assembly output looking for constant values.
> When using DWARF5 those constants might use DW_FORM_implicit_const,
> which are output (in the comments) after the attribute instead of
> before. To make sure these tests work introduce a -gdwarf-5 variant
> of these tests and explicitly use -gdwarf-2 for the original.

I just wonder if we want to use -gdwarf-2 rather than -gdwarf-4 in the
original, -gdwarf-5 has been the default for a couple of years and thus
that is what those testshave been compiled with.
Also not sure about the -dwarf5 suffixes, couldn't we say just use
pr41445-{7,8}.c, inline-var-2.C or inline3.c (or whatever next number
with the same prefix is still unused)?

> ---
>  .../dwarf2/{inline-var-1.C => inline-var-1-dwarf5.C}      | 6 ++++--
>  gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C          | 2 +-
>  .../gcc.dg/debug/dwarf2/{inline2.c => inline2-dwarf5.c}   | 7 ++++---
>  gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c               | 4 +++-
>  .../debug/dwarf2/{pr41445-5.c => pr41445-5-dwarf5.c}      | 8 ++++----
>  gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c             | 2 +-
>  .../debug/dwarf2/{pr41445-6.c => pr41445-6-dwarf5.c}      | 8 ++++----
>  gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c             | 2 +-
>  8 files changed, 22 insertions(+), 17 deletions(-)
>  copy gcc/testsuite/g++.dg/debug/dwarf2/{inline-var-1.C => inline-var-1-dwarf5.C} (76%)
>  copy gcc/testsuite/gcc.dg/debug/dwarf2/{inline2.c => inline2-dwarf5.c} (88%)
>  copy gcc/testsuite/gcc.dg/debug/dwarf2/{pr41445-5.c => pr41445-5-dwarf5.c} (73%)
>  copy gcc/testsuite/gcc.dg/debug/dwarf2/{pr41445-6.c => pr41445-6-dwarf5.c} (68%)
> 
> diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C b/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1-dwarf5.C
> similarity index 76%
> copy from gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
> copy to gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1-dwarf5.C
> index 3b1c913edfca..52ed5b6912fd 100644
> --- a/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
> +++ b/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1-dwarf5.C
> @@ -1,7 +1,9 @@
> +// DWARF5 variant of inline-var-1.C
>  // { dg-do compile { target c++17 } }
> -// { dg-options "-O -g -dA -gno-strict-dwarf -fno-eliminate-unused-debug-symbols" }
> +// { dg-options "-O -gdwarf-5 -dA -gno-strict-dwarf -fno-eliminate-unused-debug-symbols" }
>  // { dg-require-weak "" }
> -// { dg-final { scan-assembler-times "0x3\[^\n\r]* DW_AT_inline" 6 { xfail *-*-aix* } } }
> +// { dg-final { scan-assembler-times " DW_AT_inline \\(0x3\\)" 2 { xfail *-*-aix* } } }
> +// { dg-final { scan-assembler-times "0x3\[^\n\r]* DW_AT_inline" 4 { xfail *-*-aix* } } }
>  // { dg-final { scan-assembler-times "0x1\[^\n\r]* DW_AT_inline" 2 { xfail *-*-aix* } } }
>  // { dg-final { scan-assembler-times " DW_AT_declaration" 6 { xfail *-*-aix* } } }
>  // { dg-final { scan-assembler-times " DW_AT_specification" 6 { xfail *-*-aix* } } }
> diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C b/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
> index 3b1c913edfca..9a88e28cbe0f 100644
> --- a/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
> +++ b/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
> @@ -1,5 +1,5 @@
>  // { dg-do compile { target c++17 } }
> -// { dg-options "-O -g -dA -gno-strict-dwarf -fno-eliminate-unused-debug-symbols" }
> +// { dg-options "-O -gdwarf-2 -dA -gno-strict-dwarf -fno-eliminate-unused-debug-symbols" }
>  // { dg-require-weak "" }
>  // { dg-final { scan-assembler-times "0x3\[^\n\r]* DW_AT_inline" 6 { xfail *-*-aix* } } }
>  // { dg-final { scan-assembler-times "0x1\[^\n\r]* DW_AT_inline" 2 { xfail *-*-aix* } } }
> diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c b/gcc/testsuite/gcc.dg/debug/dwarf2/inline2-dwarf5.c
> similarity index 88%
> copy from gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
> copy to gcc/testsuite/gcc.dg/debug/dwarf2/inline2-dwarf5.c
> index 7e019a6c06a0..03013f11bca8 100644
> --- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
> +++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline2-dwarf5.c
> @@ -1,4 +1,4 @@
> -/* Contributed by Dodji Seketeli <dodji@redhat.com>
> +/* DWARF5 variant of inline2.
>     Origin: PR debug/37801
>  
>    Abstract instances (DW_TAG_subroutines having the DW_AT_inline attribute)
> @@ -14,7 +14,8 @@
>    properly nested DW_TAG_inlined_subroutine DIEs for third, second and first.
>  */
>  
> -/* { dg-options "-O -g3 -gdwarf -dA -fgnu89-inline" } */
> +/* Explicitly use dwarf-5 which uses DW_FORM_implicit_const.  */
> +/* { dg-options "-O -g3 -gdwarf-5 -dA -fgnu89-inline" } */
>  /* { dg-do compile } */
>  
>  /* There are 6 inlined subroutines:
> @@ -32,7 +33,7 @@
>  /* There are 3 DW_AT_inline attributes: one per abstract inline instance.
>     The value of the attribute must be 0x3, meaning the function was
>     actually inlined.  */
> -/* { dg-final { scan-assembler-times  "(?:byte|data1)\[^\n\]*0x3\[^\n\]* DW_AT_inline" 3 } } */
> +/* { dg-final { scan-assembler-times  " DW_AT_inline \\(0x3\\)" 3 } } */
>  
>  volatile int *a;
>  
> diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c b/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
> index 7e019a6c06a0..9c36450ae2de 100644
> --- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
> +++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
> @@ -14,7 +14,9 @@
>    properly nested DW_TAG_inlined_subroutine DIEs for third, second and first.
>  */
>  
> -/* { dg-options "-O -g3 -gdwarf -dA -fgnu89-inline" } */
> +/* Explicitly use dwarf-2 because dwarf-5 might use DW_FORM_implicit_const
> +   which is hard to scan for. */
> +/* { dg-options "-O -g3 -gdwarf-2 -dA -fgnu89-inline" } */
>  /* { dg-do compile } */
>  
>  /* There are 6 inlined subroutines:
> diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5-dwarf5.c
> similarity index 73%
> copy from gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
> copy to gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5-dwarf5.c
> index d646f5983b30..0e0de822d806 100644
> --- a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
> +++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5-dwarf5.c
> @@ -1,8 +1,8 @@
> -/* PR preprocessor/41445 */
> +/* PR preprocessor/41445 DWARF5 variant */
>  /* Test that token after multi-line function-like macro use
>     gets correct locus even when preprocessing separately.  */
>  /* { dg-do compile } */
> -/* { dg-options "-save-temps -gdwarf -O0 -dA -fno-merge-debug-strings" } */
> +/* { dg-options "-save-temps -gdwarf-5 -O0 -dA -fno-merge-debug-strings" } */
>  
>  #define A(x) vari x
>  #define vari(x)
> @@ -12,5 +12,5 @@ int A(B) ;
>  /*  We want to check that both vari and varj have the same line
>      number.  */
>  
> -/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"vari\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^0-9a-fA-FxX](0xa|10)\[^0-9a-fA-FxX]\[^\\r\\n\]*DW_AT_decl_line" } } */
> -/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"varj\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^0-9a-fA-FxX](0xa|10)\[^0-9a-fA-FxX]\[^\\r\\n\]*DW_AT_decl_line" } } */
> +/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"vari\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^\\r\\n\]*DW_AT_decl_line \\((0xa|10)\\)" } } */
> +/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"varj\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^\\r\\n\]*DW_AT_decl_line \\((0xa|10)\\)" } } */
> diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
> index d646f5983b30..80300ec22e87 100644
> --- a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
> +++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
> @@ -2,7 +2,7 @@
>  /* Test that token after multi-line function-like macro use
>     gets correct locus even when preprocessing separately.  */
>  /* { dg-do compile } */
> -/* { dg-options "-save-temps -gdwarf -O0 -dA -fno-merge-debug-strings" } */
> +/* { dg-options "-save-temps -gdwarf-2 -O0 -dA -fno-merge-debug-strings" } */
>  
>  #define A(x) vari x
>  #define vari(x)
> diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6-dwarf5.c
> similarity index 68%
> copy from gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
> copy to gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6-dwarf5.c
> index 340cb3835307..3a6eeb530968 100644
> --- a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
> +++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6-dwarf5.c
> @@ -1,11 +1,11 @@
> -/* PR preprocessor/41445 */
> +/* PR preprocessor/41445 DWARF5 variant*/
>  /* { dg-do compile } */
> -/* { dg-options "-gdwarf -O0 -dA -fno-merge-debug-strings" } */
> +/* { dg-options "-gdwarf-5 -O0 -dA -fno-merge-debug-strings" } */
>  
>  #include "pr41445-5.c"
>  
>  /*  We want to check that both vari and varj have the same line
>      number.  */
>  
> -/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"vari\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^0-9a-fA-FxX](0xa|10)?\[^0-9a-fA-FxX]\[^\\r\\n\]*DW_AT_decl_line" } } */
> -/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"varj\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^0-9a-fA-FxX](0xa|10)\[^0-9a-fA-FxX]\[^\\r\\n\]*DW_AT_decl_line" } } */
> +/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"vari\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^\\r\\n\]*DW_AT_decl_line \\((0xa|10)\\)" } } */
> +/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"varj\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^\\r\\n\]*DW_AT_decl_line \\((0xa|10)\\)" } } */
> diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
> index 340cb3835307..fbf033758b6b 100644
> --- a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
> +++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
> @@ -1,6 +1,6 @@
>  /* PR preprocessor/41445 */
>  /* { dg-do compile } */
> -/* { dg-options "-gdwarf -O0 -dA -fno-merge-debug-strings" } */
> +/* { dg-options "-gdwarf-2 -O0 -dA -fno-merge-debug-strings" } */
>  
>  #include "pr41445-5.c"
>  
> -- 
> 2.18.4

	Jakub

Re: [PATCH 3/5] Add DWARF5 variants of assembly scan tests that use DW_FORM_implicit_const

[Mark Wielaard]

On Mon, Aug 24, 2020 at 07:44:27PM +0200, Jakub Jelinek wrote:
> On Mon, Aug 24, 2020 at 02:56:56PM +0200, Mark Wielaard wrote:
> > Some DWARF tests scan the assembly output looking for constant values.
> > When using DWARF5 those constants might use DW_FORM_implicit_const,
> > which are output (in the comments) after the attribute instead of
> > before. To make sure these tests work introduce a -gdwarf-5 variant
> > of these tests and explicitly use -gdwarf-2 for the original.
> 
> I just wonder if we want to use -gdwarf-2 rather than -gdwarf-4 in the
> original, -gdwarf-5 has been the default for a couple of years and thus
> that is what those testshave been compiled with.

I used -gdwarf-2 because I thought that was still the default for some
arches/platforms. And they pass with -gdwarf-2.

> Also not sure about the -dwarf5 suffixes, couldn't we say just use
> pr41445-{7,8}.c, inline-var-2.C or inline3.c (or whatever next number
> with the same prefix is still unused)?

Sure, if that is a better naming scheme I'll rename them.

Cheers,

Mark

Re: [PATCH 3/5] Add DWARF5 variants of assembly scan tests that use DW_FORM_implicit_const

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

On Mon, 2020-08-24 at 22:26 +0200, Mark Wielaard wrote:
> On Mon, Aug 24, 2020 at 07:44:27PM +0200, Jakub Jelinek wrote:
> > On Mon, Aug 24, 2020 at 02:56:56PM +0200, Mark Wielaard wrote:
> > > Some DWARF tests scan the assembly output looking for constant values.
> > > When using DWARF5 those constants might use DW_FORM_implicit_const,
> > > which are output (in the comments) after the attribute instead of
> > > before. To make sure these tests work introduce a -gdwarf-5 variant
> > > of these tests and explicitly use -gdwarf-2 for the original.
> > 
> > I just wonder if we want to use -gdwarf-2 rather than -gdwarf-4 in the
> > original, -gdwarf-5 has been the default for a couple of years and thus
> > that is what those testshave been compiled with.
> 
> I used -gdwarf-2 because I thought that was still the default for some
> arches/platforms. And they pass with -gdwarf-2.
> 
> > Also not sure about the -dwarf5 suffixes, couldn't we say just use
> > pr41445-{7,8}.c, inline-var-2.C or inline3.c (or whatever next number
> > with the same prefix is still unused)?
> 
> Sure, if that is a better naming scheme I'll rename them.

Here is the adjusted patch.

gcc/testsuite/ChangeLog:

        * gcc.dg/debug/dwarf2/inline2.c: Add -gdwarf-2.
        * g++.dg/debug/dwarf2/inline-var-1.C: Likewise.
        * gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c: Likewise.
        * gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c: Likewise.
        * gcc.dg/debug/dwarf2/inline6.c: New variant with -gdwarf-5.
        * g++.dg/debug/dwarf2/inline-var-3.C: Likewise.
        * gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-7.c: Likewise.
        * gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-8.c: Likewise.

OK to commit?


[-- Attachment #2: 0001-Add-DWARF5-variants-of-assembly-scan-tests-that-use-.patch --]
[-- Type: text/x-patch, Size: 10635 bytes --]

From 99e4e5bca0d55971c515b98188ec6f206517267d Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mark@klomp.org>
Date: Sun, 23 Aug 2020 16:21:08 +0200
Subject: [PATCH] Add DWARF5 variants of assembly scan tests that use
 DW_FORM_implicit_const

Some DWARF tests scan the assembly output looking for constant values.
When using DWARF5 those constants might use DW_FORM_implicit_const,
which are output (in the comments) after the attribute instead of
before. To make sure these tests work introduce a -gdwarf-5 variant
of these tests and explicitly use -gdwarf-2 for the original.

gcc/testsuite/ChangeLog:

	* gcc.dg/debug/dwarf2/inline2.c: Add -gdwarf-2.
	* g++.dg/debug/dwarf2/inline-var-1.C: Likewise.
	* gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c: Likewise.
	* gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c: Likewise.
	* gcc.dg/debug/dwarf2/inline6.c: New variant with -gdwarf-5.
	* g++.dg/debug/dwarf2/inline-var-3.C: Likewise.
	* gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-7.c: Likewise.
	* gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-8.c: Likewise.
---
 gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C          | 2 +-
 .../debug/dwarf2/{inline-var-1.C => inline-var-3.C}       | 6 ++++--
 gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c               | 4 +++-
 .../gcc.dg/debug/dwarf2/{inline2.c => inline6.c}          | 7 ++++---
 gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c             | 2 +-
 gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c             | 2 +-
 .../gcc.dg/debug/dwarf2/{pr41445-5.c => pr41445-7.c}      | 8 ++++----
 .../gcc.dg/debug/dwarf2/{pr41445-6.c => pr41445-8.c}      | 8 ++++----
 8 files changed, 22 insertions(+), 17 deletions(-)
 copy gcc/testsuite/g++.dg/debug/dwarf2/{inline-var-1.C => inline-var-3.C} (76%)
 copy gcc/testsuite/gcc.dg/debug/dwarf2/{inline2.c => inline6.c} (88%)
 copy gcc/testsuite/gcc.dg/debug/dwarf2/{pr41445-5.c => pr41445-7.c} (73%)
 copy gcc/testsuite/gcc.dg/debug/dwarf2/{pr41445-6.c => pr41445-8.c} (68%)

diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C b/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
index 3b1c913edfca..9a88e28cbe0f 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
@@ -1,5 +1,5 @@
 // { dg-do compile { target c++17 } }
-// { dg-options "-O -g -dA -gno-strict-dwarf -fno-eliminate-unused-debug-symbols" }
+// { dg-options "-O -gdwarf-2 -dA -gno-strict-dwarf -fno-eliminate-unused-debug-symbols" }
 // { dg-require-weak "" }
 // { dg-final { scan-assembler-times "0x3\[^\n\r]* DW_AT_inline" 6 { xfail *-*-aix* } } }
 // { dg-final { scan-assembler-times "0x1\[^\n\r]* DW_AT_inline" 2 { xfail *-*-aix* } } }
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C b/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-3.C
similarity index 76%
copy from gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
copy to gcc/testsuite/g++.dg/debug/dwarf2/inline-var-3.C
index 3b1c913edfca..52ed5b6912fd 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-3.C
@@ -1,7 +1,9 @@
+// DWARF5 variant of inline-var-1.C
 // { dg-do compile { target c++17 } }
-// { dg-options "-O -g -dA -gno-strict-dwarf -fno-eliminate-unused-debug-symbols" }
+// { dg-options "-O -gdwarf-5 -dA -gno-strict-dwarf -fno-eliminate-unused-debug-symbols" }
 // { dg-require-weak "" }
-// { dg-final { scan-assembler-times "0x3\[^\n\r]* DW_AT_inline" 6 { xfail *-*-aix* } } }
+// { dg-final { scan-assembler-times " DW_AT_inline \\(0x3\\)" 2 { xfail *-*-aix* } } }
+// { dg-final { scan-assembler-times "0x3\[^\n\r]* DW_AT_inline" 4 { xfail *-*-aix* } } }
 // { dg-final { scan-assembler-times "0x1\[^\n\r]* DW_AT_inline" 2 { xfail *-*-aix* } } }
 // { dg-final { scan-assembler-times " DW_AT_declaration" 6 { xfail *-*-aix* } } }
 // { dg-final { scan-assembler-times " DW_AT_specification" 6 { xfail *-*-aix* } } }
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c b/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
index 7e019a6c06a0..9c36450ae2de 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
@@ -14,7 +14,9 @@
   properly nested DW_TAG_inlined_subroutine DIEs for third, second and first.
 */
 
-/* { dg-options "-O -g3 -gdwarf -dA -fgnu89-inline" } */
+/* Explicitly use dwarf-2 because dwarf-5 might use DW_FORM_implicit_const
+   which is hard to scan for. */
+/* { dg-options "-O -g3 -gdwarf-2 -dA -fgnu89-inline" } */
 /* { dg-do compile } */
 
 /* There are 6 inlined subroutines:
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c b/gcc/testsuite/gcc.dg/debug/dwarf2/inline6.c
similarity index 88%
copy from gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
copy to gcc/testsuite/gcc.dg/debug/dwarf2/inline6.c
index 7e019a6c06a0..03013f11bca8 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline6.c
@@ -1,4 +1,4 @@
-/* Contributed by Dodji Seketeli <dodji@redhat.com>
+/* DWARF5 variant of inline2.
    Origin: PR debug/37801
 
   Abstract instances (DW_TAG_subroutines having the DW_AT_inline attribute)
@@ -14,7 +14,8 @@
   properly nested DW_TAG_inlined_subroutine DIEs for third, second and first.
 */
 
-/* { dg-options "-O -g3 -gdwarf -dA -fgnu89-inline" } */
+/* Explicitly use dwarf-5 which uses DW_FORM_implicit_const.  */
+/* { dg-options "-O -g3 -gdwarf-5 -dA -fgnu89-inline" } */
 /* { dg-do compile } */
 
 /* There are 6 inlined subroutines:
@@ -32,7 +33,7 @@
 /* There are 3 DW_AT_inline attributes: one per abstract inline instance.
    The value of the attribute must be 0x3, meaning the function was
    actually inlined.  */
-/* { dg-final { scan-assembler-times  "(?:byte|data1)\[^\n\]*0x3\[^\n\]* DW_AT_inline" 3 } } */
+/* { dg-final { scan-assembler-times  " DW_AT_inline \\(0x3\\)" 3 } } */
 
 volatile int *a;
 
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
index d646f5983b30..80300ec22e87 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
@@ -2,7 +2,7 @@
 /* Test that token after multi-line function-like macro use
    gets correct locus even when preprocessing separately.  */
 /* { dg-do compile } */
-/* { dg-options "-save-temps -gdwarf -O0 -dA -fno-merge-debug-strings" } */
+/* { dg-options "-save-temps -gdwarf-2 -O0 -dA -fno-merge-debug-strings" } */
 
 #define A(x) vari x
 #define vari(x)
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
index 340cb3835307..fbf033758b6b 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
@@ -1,6 +1,6 @@
 /* PR preprocessor/41445 */
 /* { dg-do compile } */
-/* { dg-options "-gdwarf -O0 -dA -fno-merge-debug-strings" } */
+/* { dg-options "-gdwarf-2 -O0 -dA -fno-merge-debug-strings" } */
 
 #include "pr41445-5.c"
 
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-7.c
similarity index 73%
copy from gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
copy to gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-7.c
index d646f5983b30..0e0de822d806 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-7.c
@@ -1,8 +1,8 @@
-/* PR preprocessor/41445 */
+/* PR preprocessor/41445 DWARF5 variant */
 /* Test that token after multi-line function-like macro use
    gets correct locus even when preprocessing separately.  */
 /* { dg-do compile } */
-/* { dg-options "-save-temps -gdwarf -O0 -dA -fno-merge-debug-strings" } */
+/* { dg-options "-save-temps -gdwarf-5 -O0 -dA -fno-merge-debug-strings" } */
 
 #define A(x) vari x
 #define vari(x)
@@ -12,5 +12,5 @@ int A(B) ;
 /*  We want to check that both vari and varj have the same line
     number.  */
 
-/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"vari\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^0-9a-fA-FxX](0xa|10)\[^0-9a-fA-FxX]\[^\\r\\n\]*DW_AT_decl_line" } } */
-/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"varj\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^0-9a-fA-FxX](0xa|10)\[^0-9a-fA-FxX]\[^\\r\\n\]*DW_AT_decl_line" } } */
+/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"vari\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^\\r\\n\]*DW_AT_decl_line \\((0xa|10)\\)" } } */
+/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"varj\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^\\r\\n\]*DW_AT_decl_line \\((0xa|10)\\)" } } */
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-8.c
similarity index 68%
copy from gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
copy to gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-8.c
index 340cb3835307..3a6eeb530968 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-8.c
@@ -1,11 +1,11 @@
-/* PR preprocessor/41445 */
+/* PR preprocessor/41445 DWARF5 variant*/
 /* { dg-do compile } */
-/* { dg-options "-gdwarf -O0 -dA -fno-merge-debug-strings" } */
+/* { dg-options "-gdwarf-5 -O0 -dA -fno-merge-debug-strings" } */
 
 #include "pr41445-5.c"
 
 /*  We want to check that both vari and varj have the same line
     number.  */
 
-/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"vari\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^0-9a-fA-FxX](0xa|10)?\[^0-9a-fA-FxX]\[^\\r\\n\]*DW_AT_decl_line" } } */
-/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"varj\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^0-9a-fA-FxX](0xa|10)\[^0-9a-fA-FxX]\[^\\r\\n\]*DW_AT_decl_line" } } */
+/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"vari\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^\\r\\n\]*DW_AT_decl_line \\((0xa|10)\\)" } } */
+/* { dg-final { scan-assembler "DW_TAG_variable\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\"varj\[^\\r\\n\]*DW_AT_name(\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*DW_AT_)*\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\[^\\r\\n\]*DW_AT_decl_line \\((0xa|10)\\)" } } */
-- 
2.18.4

Re: [PATCH 3/5] Add DWARF5 variants of assembly scan tests that use DW_FORM_implicit_const

[Jakub Jelinek]

On Thu, Sep 17, 2020 at 06:03:28PM +0200, Mark Wielaard wrote:
> On Mon, 2020-08-24 at 22:26 +0200, Mark Wielaard wrote:
> > On Mon, Aug 24, 2020 at 07:44:27PM +0200, Jakub Jelinek wrote:
> > > On Mon, Aug 24, 2020 at 02:56:56PM +0200, Mark Wielaard wrote:
> > > > Some DWARF tests scan the assembly output looking for constant values.
> > > > When using DWARF5 those constants might use DW_FORM_implicit_const,
> > > > which are output (in the comments) after the attribute instead of
> > > > before. To make sure these tests work introduce a -gdwarf-5 variant
> > > > of these tests and explicitly use -gdwarf-2 for the original.
> > > 
> > > I just wonder if we want to use -gdwarf-2 rather than -gdwarf-4 in the
> > > original, -gdwarf-5 has been the default for a couple of years and thus
> > > that is what those testshave been compiled with.
> > 
> > I used -gdwarf-2 because I thought that was still the default for some
> > arches/platforms. And they pass with -gdwarf-2.
> > 
> > > Also not sure about the -dwarf5 suffixes, couldn't we say just use
> > > pr41445-{7,8}.c, inline-var-2.C or inline3.c (or whatever next number
> > > with the same prefix is still unused)?
> > 
> > Sure, if that is a better naming scheme I'll rename them.
> 
> Here is the adjusted patch.
> 
> gcc/testsuite/ChangeLog:
> 
>         * gcc.dg/debug/dwarf2/inline2.c: Add -gdwarf-2.
>         * g++.dg/debug/dwarf2/inline-var-1.C: Likewise.
>         * gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c: Likewise.
>         * gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-6.c: Likewise.
>         * gcc.dg/debug/dwarf2/inline6.c: New variant with -gdwarf-5.
>         * g++.dg/debug/dwarf2/inline-var-3.C: Likewise.
>         * gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-7.c: Likewise.
>         * gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-8.c: Likewise.
> 
> OK to commit?

Ok, thanks.

	Jakub

[PATCH 4/5] Default to DWARF5

[Mark Wielaard]

---
 gcc/common.opt      | 2 +-
 gcc/doc/invoke.texi | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index 513125f0c00b..05e4e0638ecb 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3144,7 +3144,7 @@ Common Driver JoinedOrMissing Negative(gdwarf-)
 Generate debug information in default version of DWARF format.
 
 gdwarf-
-Common Driver Joined UInteger Var(dwarf_version) Init(4) Negative(gstabs)
+Common Driver Joined UInteger Var(dwarf_version) Init(5) Negative(gstabs)
 Generate debug information in DWARF v2 (or later) format.
 
 ggdb
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index e5dddc236d7d..51ffff1fcd25 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9042,13 +9042,14 @@ possible.
 @opindex gdwarf
 Produce debugging information in DWARF format (if that is supported).
 The value of @var{version} may be either 2, 3, 4 or 5; the default version
-for most targets is 4.  DWARF Version 5 is only experimental.
+for most targets is 5 (with the exception of vxworks and darwin which
+default to version 2).
 
 Note that with DWARF Version 2, some ports require and always
 use some non-conflicting DWARF 3 extensions in the unwind tables.
 
 Version 4 may require GDB 7.0 and @option{-fvar-tracking-assignments}
-for maximum benefit.
+for maximum benefit. Version 5 requires GDB 8.0 or higher.
 
 GCC no longer supports DWARF Version 1, which is substantially
 different than Version 2 and later.  For historical reasons, some
-- 
2.18.4

[PATCH 5/5] Add --gdwarf-5 to ASM_SPEC

[Mark Wielaard]

This is needed to get DWARF version 5 .debug_line tables.
It is also obviously wrong. It needs a check for whether as supports
--gdwarf-<version> for all versions we support and it should only
be added when generating DWARF debug information for the specific
DWARF version we are generating.

It also needs some fixes to binutils, to make sure the line table is
generated correctly:
https://sourceware.org/pipermail/binutils/2020-August/112685.html
And to make sure it can read the generated line table itself:
https://sourceware.org/pipermail/binutils/2020-August/112966.html
---
 gcc/gcc.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/gcc/gcc.c b/gcc/gcc.c
index 10bc9881aed3..98b10e7cd154 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -1882,6 +1882,11 @@ init_spec (void)
   }
 #endif
 
+  static const char dv[] = "--gdwarf-5 ";
+  obstack_grow (&obstack, dv, sizeof (dv) - 1);
+  obstack_grow0 (&obstack, asm_spec, strlen (asm_spec));
+  asm_spec = XOBFINISH (&obstack, const char *);
+
 #if defined LINK_EH_SPEC || defined LINK_BUILDID_SPEC || \
     defined LINKER_HASH_STYLE
 # ifdef LINK_BUILDID_SPEC
-- 
2.18.4

Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

[Mark Wielaard]

Hi gcc hackers, binutils hackers,

Nick, Jakub and I were discussing the gcc patch below and all the ways
it is wrong. Most things can be fixed in the spec. Like only passing
-gdwarf if we are generating DWARF and passing the right DWARF version
as -gdwarf-N for the version that gcc itself creates. But whether or
not we want gas to generate .debug_line info is a bit tricky. But when
giving -gdwarf-N gas will always try to generate a .debug_line section
and error out when there is already one.

Would it be possible to have something like the following in gas, so
that it doesn't try generating a .debug_line section if there already
is one, even when -gdwarf-N is given (unless the assembly also
contains .loc directives because that shows the user is really
confused)?

diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c
index e4ba56d82ba..c0c09f4e9d0 100644
--- a/gas/dwarf2dbg.c
+++ b/gas/dwarf2dbg.c
@@ -2626,7 +2626,7 @@ dwarf2_init (void)
 
 
 /* Finish the dwarf2 debug sections.  We emit .debug.line if there
-   were any .file/.loc directives, or --gdwarf2 was given, or if the
+   were any .file/.loc directives, or --gdwarf2 was given, and if the
    file has a non-empty .debug_info section and an empty .debug_line
    section.  If we emit .debug_line, and the .debug_info section is
    empty, we also emit .debug_info, .debug_aranges and .debug_abbrev.
@@ -2650,9 +2650,16 @@ dwarf2_finish (void)
   empty_debug_line = line_seg == NULL || !seg_not_empty_p (line_seg);
 
   /* We can't construct a new debug_line section if we already have one.
-     Give an error.  */
+     Give an error if we have seen any .loc, otherwise trust the user
+     knows what they are doing and want to generate the .debug_line
+     (and all other debug sections) themselves.  */
   if (all_segs && !empty_debug_line)
-    as_fatal ("duplicate .debug_line sections");
+    {
+      if (dwarf2_loc_directive_seen)
+	as_fatal ("duplicate .debug_line sections");
+      else
+	return;
+    }
 
   if ((!all_segs && emit_other_sections)
       || (!emit_other_sections && !empty_debug_line))

On Mon, Aug 24, 2020 at 02:56:58PM +0200, Mark Wielaard wrote:
> This is needed to get DWARF version 5 .debug_line tables.
> It is also obviously wrong. It needs a check for whether as supports
> --gdwarf-<version> for all versions we support and it should only
> be added when generating DWARF debug information for the specific
> DWARF version we are generating.
> 
> It also needs some fixes to binutils, to make sure the line table is
> generated correctly:
> https://sourceware.org/pipermail/binutils/2020-August/112685.html
> And to make sure it can read the generated line table itself:
> https://sourceware.org/pipermail/binutils/2020-August/112966.html
> ---
>  gcc/gcc.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/gcc/gcc.c b/gcc/gcc.c
> index 10bc9881aed3..98b10e7cd154 100644
> --- a/gcc/gcc.c
> +++ b/gcc/gcc.c
> @@ -1882,6 +1882,11 @@ init_spec (void)
>    }
>  #endif
>  
> +  static const char dv[] = "--gdwarf-5 ";
> +  obstack_grow (&obstack, dv, sizeof (dv) - 1);
> +  obstack_grow0 (&obstack, asm_spec, strlen (asm_spec));
> +  asm_spec = XOBFINISH (&obstack, const char *);
> +
>  #if defined LINK_EH_SPEC || defined LINK_BUILDID_SPEC || \
>      defined LINKER_HASH_STYLE
>  # ifdef LINK_BUILDID_SPEC
> -- 
> 2.18.4
> 

Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

[H.J. Lu]

On Wed, Aug 26, 2020 at 2:38 PM Mark Wielaard <mark@klomp.org> wrote:
>
> Hi gcc hackers, binutils hackers,
>
> Nick, Jakub and I were discussing the gcc patch below and all the ways
> it is wrong. Most things can be fixed in the spec. Like only passing
> -gdwarf if we are generating DWARF and passing the right DWARF version
> as -gdwarf-N for the version that gcc itself creates. But whether or
> not we want gas to generate .debug_line info is a bit tricky. But when
> giving -gdwarf-N gas will always try to generate a .debug_line section
> and error out when there is already one.
>
> Would it be possible to have something like the following in gas, so
> that it doesn't try generating a .debug_line section if there already
> is one, even when -gdwarf-N is given (unless the assembly also
> contains .loc directives because that shows the user is really
> confused)?
>
> diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c
> index e4ba56d82ba..c0c09f4e9d0 100644
> --- a/gas/dwarf2dbg.c
> +++ b/gas/dwarf2dbg.c
> @@ -2626,7 +2626,7 @@ dwarf2_init (void)
>
>
>  /* Finish the dwarf2 debug sections.  We emit .debug.line if there
> -   were any .file/.loc directives, or --gdwarf2 was given, or if the
> +   were any .file/.loc directives, or --gdwarf2 was given, and if the
>     file has a non-empty .debug_info section and an empty .debug_line
>     section.  If we emit .debug_line, and the .debug_info section is
>     empty, we also emit .debug_info, .debug_aranges and .debug_abbrev.
> @@ -2650,9 +2650,16 @@ dwarf2_finish (void)
>    empty_debug_line = line_seg == NULL || !seg_not_empty_p (line_seg);
>
>    /* We can't construct a new debug_line section if we already have one.
> -     Give an error.  */
> +     Give an error if we have seen any .loc, otherwise trust the user
> +     knows what they are doing and want to generate the .debug_line
> +     (and all other debug sections) themselves.  */
>    if (all_segs && !empty_debug_line)
> -    as_fatal ("duplicate .debug_line sections");
> +    {
> +      if (dwarf2_loc_directive_seen)
> +       as_fatal ("duplicate .debug_line sections");
> +      else
> +       return;
> +    }
>
>    if ((!all_segs && emit_other_sections)
>        || (!emit_other_sections && !empty_debug_line))
>

I have run into this issue before.  "as -g" shouldn't silently
generate incorrect
debug info when input assembly codes already contain debug directives.
AS should either issue an error or ignore -g.  In either case, we need
a testcase
to verify it.

-- 
H.J.

Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

[Mark Wielaard]

Hi,

On Wed, Aug 26, 2020 at 04:38:21PM -0700, H.J. Lu wrote:
> On Wed, Aug 26, 2020 at 2:38 PM Mark Wielaard <mark@klomp.org> wrote:
> > Would it be possible to have something like the following in gas, so
> > that it doesn't try generating a .debug_line section if there already
> > is one, even when -gdwarf-N is given (unless the assembly also
> > contains .loc directives because that shows the user is really
> > confused)?
> >
> > diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c
> > index e4ba56d82ba..c0c09f4e9d0 100644
> > --- a/gas/dwarf2dbg.c
> > +++ b/gas/dwarf2dbg.c
> > @@ -2626,7 +2626,7 @@ dwarf2_init (void)
> >
> >
> >  /* Finish the dwarf2 debug sections.  We emit .debug.line if there
> > -   were any .file/.loc directives, or --gdwarf2 was given, or if the
> > +   were any .file/.loc directives, or --gdwarf2 was given, and if the
> >     file has a non-empty .debug_info section and an empty .debug_line
> >     section.  If we emit .debug_line, and the .debug_info section is
> >     empty, we also emit .debug_info, .debug_aranges and .debug_abbrev.
> > @@ -2650,9 +2650,16 @@ dwarf2_finish (void)
> >    empty_debug_line = line_seg == NULL || !seg_not_empty_p (line_seg);
> >
> >    /* We can't construct a new debug_line section if we already have one.
> > -     Give an error.  */
> > +     Give an error if we have seen any .loc, otherwise trust the user
> > +     knows what they are doing and want to generate the .debug_line
> > +     (and all other debug sections) themselves.  */
> >    if (all_segs && !empty_debug_line)
> > -    as_fatal ("duplicate .debug_line sections");
> > +    {
> > +      if (dwarf2_loc_directive_seen)
> > +       as_fatal ("duplicate .debug_line sections");
> > +      else
> > +       return;
> > +    }
> >
> >    if ((!all_segs && emit_other_sections)
> >        || (!emit_other_sections && !empty_debug_line))
> >
>
> I have run into this issue before.  "as -g" shouldn't silently
> generate incorrect debug info when input assembly codes already
> contain debug directives.  AS should either issue an error or
> ignore -g.

Right, that is what this patch does for .debug_line.  gas already
doesn't generate .debug_info, .debug_aranges and .debug_abbrev if
.debug_info is non-empty, even if -g is given.

> In either case, we need a testcase  to verify it.

Right, and the documentation needs to be update.  But first we have to
know whether the gas maintainers think this is the right approach.

Cheers,

Mark

Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

[H.J. Lu]

On Sat, Aug 29, 2020 at 5:24 AM Mark Wielaard <mark@klomp.org> wrote:
>
> Hi,
>
> On Wed, Aug 26, 2020 at 04:38:21PM -0700, H.J. Lu wrote:
> > On Wed, Aug 26, 2020 at 2:38 PM Mark Wielaard <mark@klomp.org> wrote:
> > > Would it be possible to have something like the following in gas, so
> > > that it doesn't try generating a .debug_line section if there already
> > > is one, even when -gdwarf-N is given (unless the assembly also
> > > contains .loc directives because that shows the user is really
> > > confused)?
> > >
> > > diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c
> > > index e4ba56d82ba..c0c09f4e9d0 100644
> > > --- a/gas/dwarf2dbg.c
> > > +++ b/gas/dwarf2dbg.c
> > > @@ -2626,7 +2626,7 @@ dwarf2_init (void)
> > >
> > >
> > >  /* Finish the dwarf2 debug sections.  We emit .debug.line if there
> > > -   were any .file/.loc directives, or --gdwarf2 was given, or if the
> > > +   were any .file/.loc directives, or --gdwarf2 was given, and if the
> > >     file has a non-empty .debug_info section and an empty .debug_line
> > >     section.  If we emit .debug_line, and the .debug_info section is
> > >     empty, we also emit .debug_info, .debug_aranges and .debug_abbrev.
> > > @@ -2650,9 +2650,16 @@ dwarf2_finish (void)
> > >    empty_debug_line = line_seg == NULL || !seg_not_empty_p (line_seg);
> > >
> > >    /* We can't construct a new debug_line section if we already have one.
> > > -     Give an error.  */
> > > +     Give an error if we have seen any .loc, otherwise trust the user
> > > +     knows what they are doing and want to generate the .debug_line
> > > +     (and all other debug sections) themselves.  */
> > >    if (all_segs && !empty_debug_line)
> > > -    as_fatal ("duplicate .debug_line sections");
> > > +    {
> > > +      if (dwarf2_loc_directive_seen)
> > > +       as_fatal ("duplicate .debug_line sections");
> > > +      else
> > > +       return;
> > > +    }
> > >
> > >    if ((!all_segs && emit_other_sections)
> > >        || (!emit_other_sections && !empty_debug_line))
> > >
> >
> > I have run into this issue before.  "as -g" shouldn't silently
> > generate incorrect debug info when input assembly codes already
> > contain debug directives.  AS should either issue an error or
> > ignore -g.
>
> Right, that is what this patch does for .debug_line.  gas already
> doesn't generate .debug_info, .debug_aranges and .debug_abbrev if
> .debug_info is non-empty, even if -g is given.
>
> > In either case, we need a testcase  to verify it.
>
> Right, and the documentation needs to be update.  But first we have to
> know whether the gas maintainers think this is the right approach.
>

-g should be ignored in this case.


-- 
H.J.

Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

[Mark Wielaard]

Hi,

On Sat, Aug 29, 2020 at 07:34:35AM -0700, H.J. Lu wrote:
> On Sat, Aug 29, 2020 at 5:24 AM Mark Wielaard <mark@klomp.org> wrote:
> > On Wed, Aug 26, 2020 at 04:38:21PM -0700, H.J. Lu wrote:
> > > On Wed, Aug 26, 2020 at 2:38 PM Mark Wielaard <mark@klomp.org> wrote:
> > > > Would it be possible to have something like the following in gas, so
> > > > that it doesn't try generating a .debug_line section if there already
> > > > is one, even when -gdwarf-N is given (unless the assembly also
> > > > contains .loc directives because that shows the user is really
> > > > confused)?
> > > >
> > > > diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c
> > > > index e4ba56d82ba..c0c09f4e9d0 100644
> > > > --- a/gas/dwarf2dbg.c
> > > > +++ b/gas/dwarf2dbg.c
> > > > @@ -2626,7 +2626,7 @@ dwarf2_init (void)
> > > >
> > > >
> > > >  /* Finish the dwarf2 debug sections.  We emit .debug.line if there
> > > > -   were any .file/.loc directives, or --gdwarf2 was given, or if the
> > > > +   were any .file/.loc directives, or --gdwarf2 was given, and if the
> > > >     file has a non-empty .debug_info section and an empty .debug_line
> > > >     section.  If we emit .debug_line, and the .debug_info section is
> > > >     empty, we also emit .debug_info, .debug_aranges and .debug_abbrev.
> > > > @@ -2650,9 +2650,16 @@ dwarf2_finish (void)
> > > >    empty_debug_line = line_seg == NULL || !seg_not_empty_p (line_seg);
> > > >
> > > >    /* We can't construct a new debug_line section if we already have one.
> > > > -     Give an error.  */
> > > > +     Give an error if we have seen any .loc, otherwise trust the user
> > > > +     knows what they are doing and want to generate the .debug_line
> > > > +     (and all other debug sections) themselves.  */
> > > >    if (all_segs && !empty_debug_line)
> > > > -    as_fatal ("duplicate .debug_line sections");
> > > > +    {
> > > > +      if (dwarf2_loc_directive_seen)
> > > > +       as_fatal ("duplicate .debug_line sections");
> > > > +      else
> > > > +       return;
> > > > +    }
> > > >
> > > >    if ((!all_segs && emit_other_sections)
> > > >        || (!emit_other_sections && !empty_debug_line))
> > >
> > > I have run into this issue before.  "as -g" shouldn't silently
> > > generate incorrect debug info when input assembly codes already
> > > contain debug directives.  AS should either issue an error or
> > > ignore -g.
> >
> > Right, that is what this patch does for .debug_line.  gas already
> > doesn't generate .debug_info, .debug_aranges and .debug_abbrev if
> > .debug_info is non-empty, even if -g is given.
> >
> > > In either case, we need a testcase  to verify it.
> >
> > Right, and the documentation needs to be update.  But first we have to
> > know whether the gas maintainers think this is the right approach.
> 
> -g should be ignored in this case.

I am not sure what you mean by "in this case", or what precisely it
means to "ignore -g".

My proposal, and what my strawman patch implements, is that gas will
generate a .debug_line section when -g is given and the debug types is
DWARF (just as it does now). Unless there is a non-empty .debug_line
section already created by the input assembly and the input assembly
does not contain any .loc directive then gas will not try to generate
a .debug_line section itself but leaves the non-empty .debug_line as
is (currently gas will generate an error in this case). But if the
input assembly does contain both .loc directives and creates a
non-empty .debug line section gas will still generate an error (as it
does now, whether or not the input assembly contains any .loc
directives).

Does this sound sane?

Thanks,

Mark

Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

[H.J. Lu]

On Sat, Aug 29, 2020 at 8:23 AM Mark Wielaard <mark@klomp.org> wrote:
>
> Hi,
>
> On Sat, Aug 29, 2020 at 07:34:35AM -0700, H.J. Lu wrote:
> > On Sat, Aug 29, 2020 at 5:24 AM Mark Wielaard <mark@klomp.org> wrote:
> > > On Wed, Aug 26, 2020 at 04:38:21PM -0700, H.J. Lu wrote:
> > > > On Wed, Aug 26, 2020 at 2:38 PM Mark Wielaard <mark@klomp.org> wrote:
> > > > > Would it be possible to have something like the following in gas, so
> > > > > that it doesn't try generating a .debug_line section if there already
> > > > > is one, even when -gdwarf-N is given (unless the assembly also
> > > > > contains .loc directives because that shows the user is really
> > > > > confused)?
> > > > >
> > > > > diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c
> > > > > index e4ba56d82ba..c0c09f4e9d0 100644
> > > > > --- a/gas/dwarf2dbg.c
> > > > > +++ b/gas/dwarf2dbg.c
> > > > > @@ -2626,7 +2626,7 @@ dwarf2_init (void)
> > > > >
> > > > >
> > > > >  /* Finish the dwarf2 debug sections.  We emit .debug.line if there
> > > > > -   were any .file/.loc directives, or --gdwarf2 was given, or if the
> > > > > +   were any .file/.loc directives, or --gdwarf2 was given, and if the
> > > > >     file has a non-empty .debug_info section and an empty .debug_line
> > > > >     section.  If we emit .debug_line, and the .debug_info section is
> > > > >     empty, we also emit .debug_info, .debug_aranges and .debug_abbrev.
> > > > > @@ -2650,9 +2650,16 @@ dwarf2_finish (void)
> > > > >    empty_debug_line = line_seg == NULL || !seg_not_empty_p (line_seg);
> > > > >
> > > > >    /* We can't construct a new debug_line section if we already have one.
> > > > > -     Give an error.  */
> > > > > +     Give an error if we have seen any .loc, otherwise trust the user
> > > > > +     knows what they are doing and want to generate the .debug_line
> > > > > +     (and all other debug sections) themselves.  */
> > > > >    if (all_segs && !empty_debug_line)
> > > > > -    as_fatal ("duplicate .debug_line sections");
> > > > > +    {
> > > > > +      if (dwarf2_loc_directive_seen)
> > > > > +       as_fatal ("duplicate .debug_line sections");
> > > > > +      else
> > > > > +       return;
> > > > > +    }
> > > > >
> > > > >    if ((!all_segs && emit_other_sections)
> > > > >        || (!emit_other_sections && !empty_debug_line))
> > > >
> > > > I have run into this issue before.  "as -g" shouldn't silently
> > > > generate incorrect debug info when input assembly codes already
> > > > contain debug directives.  AS should either issue an error or
> > > > ignore -g.
> > >
> > > Right, that is what this patch does for .debug_line.  gas already
> > > doesn't generate .debug_info, .debug_aranges and .debug_abbrev if
> > > .debug_info is non-empty, even if -g is given.
> > >
> > > > In either case, we need a testcase  to verify it.
> > >
> > > Right, and the documentation needs to be update.  But first we have to
> > > know whether the gas maintainers think this is the right approach.
> >
> > -g should be ignored in this case.
>
> I am not sure what you mean by "in this case", or what precisely it
> means to "ignore -g".
>
> My proposal, and what my strawman patch implements, is that gas will
> generate a .debug_line section when -g is given and the debug types is
> DWARF (just as it does now). Unless there is a non-empty .debug_line
> section already created by the input assembly and the input assembly
> does not contain any .loc directive then gas will not try to generate
> a .debug_line section itself but leaves the non-empty .debug_line as
> is (currently gas will generate an error in this case). But if the
> input assembly does contain both .loc directives and creates a
> non-empty .debug line section gas will still generate an error (as it
> does now, whether or not the input assembly contains any .loc
> directives).
>
> Does this sound sane?

What if there is a .file directive,  but without .loc directive, like

$ gcc -c x.c -Wa,-g


-- 
H.J.

Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

[Mark Wielaard]

Hi,

On Sat, Aug 29, 2020 at 08:43:30AM -0700, H.J. Lu wrote:
> On Sat, Aug 29, 2020 at 8:23 AM Mark Wielaard <mark@klomp.org> wrote:
> > My proposal, and what my strawman patch implements, is that gas will
> > generate a .debug_line section when -g is given and the debug types is
> > DWARF (just as it does now). Unless there is a non-empty .debug_line
> > section already created by the input assembly and the input assembly
> > does not contain any .loc directive then gas will not try to generate
> > a .debug_line section itself but leaves the non-empty .debug_line as
> > is (currently gas will generate an error in this case). But if the
> > input assembly does contain both .loc directives and creates a
> > non-empty .debug line section gas will still generate an error (as it
> > does now, whether or not the input assembly contains any .loc
> > directives).
> >
> > Does this sound sane?
> 
> What if there is a .file directive,  but without .loc directive, like
> 
> $ gcc -c x.c -Wa,-g

That situation does not change, since in that case no .debug_*
sections are generated in the assembly file, so gas will generate
everything it currently generates.

Cheers,

Mark

Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

[H.J. Lu]

On Sat, Aug 29, 2020 at 9:33 AM Mark Wielaard <mark@klomp.org> wrote:
>
> Hi,
>
> On Sat, Aug 29, 2020 at 08:43:30AM -0700, H.J. Lu wrote:
> > On Sat, Aug 29, 2020 at 8:23 AM Mark Wielaard <mark@klomp.org> wrote:
> > > My proposal, and what my strawman patch implements, is that gas will
> > > generate a .debug_line section when -g is given and the debug types is
> > > DWARF (just as it does now). Unless there is a non-empty .debug_line
> > > section already created by the input assembly and the input assembly
> > > does not contain any .loc directive then gas will not try to generate
> > > a .debug_line section itself but leaves the non-empty .debug_line as
> > > is (currently gas will generate an error in this case). But if the
> > > input assembly does contain both .loc directives and creates a
> > > non-empty .debug line section gas will still generate an error (as it
> > > does now, whether or not the input assembly contains any .loc
> > > directives).
> > >
> > > Does this sound sane?
> >
> > What if there is a .file directive,  but without .loc directive, like
> >
> > $ gcc -c x.c -Wa,-g
>
> That situation does not change, since in that case no .debug_*
> sections are generated in the assembly file, so gas will generate
> everything it currently generates.
>

Will line info be correct in this case?


-- 
H.J.

Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

[Mark Wielaard]

H.J. Lu wrote:
> On Sat, Aug 29, 2020 at 9:33 AM Mark Wielaard <mark@klomp.org> wrote:
>> Hi,
>>
>> On Sat, Aug 29, 2020 at 08:43:30AM -0700, H.J. Lu wrote:
>>> On Sat, Aug 29, 2020 at 8:23 AM Mark Wielaard <mark@klomp.org> wrote:
>>>> My proposal, and what my strawman patch implements, is that gas will
>>>> generate a .debug_line section when -g is given and the debug types is
>>>> DWARF (just as it does now). Unless there is a non-empty .debug_line
>>>> section already created by the input assembly and the input assembly
>>>> does not contain any .loc directive then gas will not try to generate
>>>> a .debug_line section itself but leaves the non-empty .debug_line as
>>>> is (currently gas will generate an error in this case). But if the
>>>> input assembly does contain both .loc directives and creates a
>>>> non-empty .debug line section gas will still generate an error (as it
>>>> does now, whether or not the input assembly contains any .loc
>>>> directives).
>>>>
>>>> Does this sound sane?
>>>
>>> What if there is a .file directive,  but without .loc directive, like
>>>
>>> $ gcc -c x.c -Wa,-g
>>
>> That situation does not change, since in that case no .debug_*
>> sections are generated in the assembly file, so gas will generate
>> everything it currently generates.
>
> Will line info be correct in this case?

Nothing about how gas generates the line table will change with the above proposal. It only changes the behaviour when the assembly already contains a line table.

[PATCH] gas: Don't error when .debug_line already exists, unless .loc was used

[Mark Wielaard]

When -g was used to generate DWARF gas would error out when a .debug_line
already exists. But when a .debug_info section already exists it would
simply skip generating one without warning or error. Do the same for
.debug_line. It is only an error when the user explicitly uses .loc
directives and also generates the .debug_line table itself.

The tests are unfortunately arch specific because the line table is only
generated when actual instructions have been emitted. Use i386 because
that is probably the most used architecture. Before this patch the new
dwarf-line-2 testcase would fail, with this patch it succeeds (and doesn't
try to add its own line table).

gas/ChangeLog:

    * as.texi (-g): Explicitly mention when .debug_info and .debug_line
    are generated for the DWARF format.
    (Loc): Add that it is an error to both use a .loc directive and
    generate a .debug_line yourself.
    * dwarf2dbg.c (dwarf2_any_loc_directive_seen): New static variable.
    (dwarf2_directive_loc): Set dwarf2_any_loc_directive_seen to TRUE.
    (dwarf2_finish): Check dwarf2_any_loc_directive_seen before emitting
    an error. Only create .debug_line if it is empty (or doesn't exist).
    * testsuite/gas/i386/i386.exp: Add dwarf2-line-{1,2,3,4} when testing
    an elf target.
    * testsuite/gas/i386/dwarf2-line-{1,2,3,4}.{s,d,l}: New test files.
---
 gas/ChangeLog                          | 14 ++++
 gas/doc/as.texi                        |  7 +-
 gas/dwarf2dbg.c                        | 29 +++++---
 gas/testsuite/gas/i386/dwarf2-line-1.d | 45 +++++++++++++
 gas/testsuite/gas/i386/dwarf2-line-1.s | 28 ++++++++
 gas/testsuite/gas/i386/dwarf2-line-2.d | 48 ++++++++++++++
 gas/testsuite/gas/i386/dwarf2-line-2.s | 91 ++++++++++++++++++++++++++
 gas/testsuite/gas/i386/dwarf2-line-3.d |  3 +
 gas/testsuite/gas/i386/dwarf2-line-3.l |  2 +
 gas/testsuite/gas/i386/dwarf2-line-3.s | 32 +++++++++
 gas/testsuite/gas/i386/dwarf2-line-4.d | 46 +++++++++++++
 gas/testsuite/gas/i386/dwarf2-line-4.s | 29 ++++++++
 gas/testsuite/gas/i386/i386.exp        |  5 ++
 13 files changed, 369 insertions(+), 10 deletions(-)
 create mode 100644 gas/testsuite/gas/i386/dwarf2-line-1.d
 create mode 100644 gas/testsuite/gas/i386/dwarf2-line-1.s
 create mode 100644 gas/testsuite/gas/i386/dwarf2-line-2.d
 create mode 100644 gas/testsuite/gas/i386/dwarf2-line-2.s
 create mode 100644 gas/testsuite/gas/i386/dwarf2-line-3.d
 create mode 100644 gas/testsuite/gas/i386/dwarf2-line-3.l
 create mode 100644 gas/testsuite/gas/i386/dwarf2-line-3.s
 create mode 100644 gas/testsuite/gas/i386/dwarf2-line-4.d
 create mode 100644 gas/testsuite/gas/i386/dwarf2-line-4.s

diff --git a/gas/ChangeLog b/gas/ChangeLog
index d34c08e924c..70d09729443 100644
--- a/gas/ChangeLog
+++ b/gas/ChangeLog
@@ -1,3 +1,17 @@
+2020-09-07  Mark Wielaard  <mark@klomp.org>
+
+	* as.texi (-g): Explicitly mention when .debug_info and .debug_line
+	are generated for the DWARF format.
+	(Loc): Add that it is an error to both use a .loc directive and
+	generate a .debug_line yourself.
+	* dwarf2dbg.c (dwarf2_any_loc_directive_seen): New static variable.
+	(dwarf2_directive_loc): Set dwarf2_any_loc_directive_seen to TRUE.
+	(dwarf2_finish): Check dwarf2_any_loc_directive_seen before emitting
+	an error. Only create .debug_line if it is empty (or doesn't exist).
+	* testsuite/gas/i386/i386.exp: Add dwarf2-line-{1,2,3,4} when testing
+	an elf target.
+	* testsuite/gas/i386/dwarf2-line-{1,2,3,4}.{s,d,l}: New test files.
+
 2020-09-04  Mark Wielaard  <mark@klomp.org>
 
 	* dwarf2dbg.c (add_line_strp): New function.
diff --git a/gas/doc/as.texi b/gas/doc/as.texi
index 112eaf810cd..f2a0314310d 100644
--- a/gas/doc/as.texi
+++ b/gas/doc/as.texi
@@ -745,7 +745,9 @@ compiler output).
 @itemx --gen-debug
 Generate debugging information for each assembler source line using whichever
 debug format is preferred by the target.  This currently means either STABS,
-ECOFF or DWARF2.
+ECOFF or DWARF2.  When the debug format is DWARF then a @code{.debug_info} and
+@code{.debug_line} section is only emitted when the assembly file doesn't
+generate one itself.
 
 @item --gstabs
 Generate stabs debugging information for each assembler line.  This
@@ -5857,7 +5859,8 @@ the @code{.loc} directive will add a row to the @code{.debug_line} line
 number matrix corresponding to the immediately following assembly
 instruction.  The @var{fileno}, @var{lineno}, and optional @var{column}
 arguments will be applied to the @code{.debug_line} state machine before
-the row is added.
+the row is added.  It is an error for the input assembly file to generate
+a non-empty @code{.debug_line} and also use @code{loc} directives.
 
 The @var{options} are a sequence of the following tokens in any order:
 
diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c
index e0ea3991b45..1c21d58c591 100644
--- a/gas/dwarf2dbg.c
+++ b/gas/dwarf2dbg.c
@@ -226,9 +226,15 @@ static unsigned int  dirs_in_use = 0;
 static unsigned int  dirs_allocated = 0;
 
 /* TRUE when we've seen a .loc directive recently.  Used to avoid
-   doing work when there's nothing to do.  */
+   doing work when there's nothing to do.  Will be reset by
+   dwarf2_consume_line_info.  */
 bfd_boolean dwarf2_loc_directive_seen;
 
+/* TRUE when we've seen any .loc directive at any time during parsing.
+   Indicates the user wants us to generate a .debug_line section.
+   Used in dwarf2_finish as sanity check.  */
+static bfd_boolean dwarf2_any_loc_directive_seen;
+
 /* TRUE when we're supposed to set the basic block mark whenever a
    label is seen.  */
 bfd_boolean dwarf2_loc_mark_labels;
@@ -1290,7 +1296,7 @@ dwarf2_directive_loc (int dummy ATTRIBUTE_UNUSED)
     }
 
   demand_empty_rest_of_line ();
-  dwarf2_loc_directive_seen = TRUE;
+  dwarf2_any_loc_directive_seen = dwarf2_loc_directive_seen = TRUE;
   debug_type = DEBUG_NONE;
 
   /* If we were given a view id, emit the row right away.  */
@@ -2737,7 +2743,7 @@ dwarf2_init (void)
 
 
 /* Finish the dwarf2 debug sections.  We emit .debug.line if there
-   were any .file/.loc directives, or --gdwarf2 was given, or if the
+   were any .file/.loc directives, or --gdwarf2 was given, and if the
    file has a non-empty .debug_info section and an empty .debug_line
    section.  If we emit .debug_line, and the .debug_info section is
    empty, we also emit .debug_info, .debug_aranges and .debug_abbrev.
@@ -2761,8 +2767,10 @@ dwarf2_finish (void)
   empty_debug_line = line_seg == NULL || !seg_not_empty_p (line_seg);
 
   /* We can't construct a new debug_line section if we already have one.
-     Give an error.  */
-  if (all_segs && !empty_debug_line)
+     Give an error if we have seen any .loc, otherwise trust the user
+     knows what they are doing and want to generate the .debug_line
+     (and all other debug sections) themselves.  */
+  if (all_segs && !empty_debug_line && dwarf2_any_loc_directive_seen)
     as_fatal ("duplicate .debug_line sections");
 
   if ((!all_segs && emit_other_sections)
@@ -2776,8 +2784,12 @@ dwarf2_finish (void)
   sizeof_address = DWARF2_ADDR_SIZE (stdoutput);
 
   /* Create and switch to the line number section.  */
-  line_seg = subseg_new (".debug_line", 0);
-  bfd_set_section_flags (line_seg, SEC_READONLY | SEC_DEBUGGING | SEC_OCTETS);
+  if (empty_debug_line)
+    {
+      line_seg = subseg_new (".debug_line", 0);
+      bfd_set_section_flags (line_seg,
+			     SEC_READONLY | SEC_DEBUGGING | SEC_OCTETS);
+    }
 
   /* For each subsection, chain the debug entries together.  */
   for (s = all_segs; s; s = s->next)
@@ -2803,7 +2815,8 @@ dwarf2_finish (void)
 	}
     }
 
-  out_debug_line (line_seg);
+  if (empty_debug_line)
+    out_debug_line (line_seg);
 
   /* If this is assembler generated line info, and there is no
      debug_info already, we need .debug_info, .debug_abbrev and
diff --git a/gas/testsuite/gas/i386/dwarf2-line-1.d b/gas/testsuite/gas/i386/dwarf2-line-1.d
new file mode 100644
index 00000000000..196f099c1a8
--- /dev/null
+++ b/gas/testsuite/gas/i386/dwarf2-line-1.d
@@ -0,0 +1,45 @@
+#as: -gdwarf-2
+#readelf: -wl
+#name: DWARF .debug_line 1
+
+Raw dump of debug contents of section \.z?debug_line:
+
+  Offset:                      0x0
+  Length:                      .*
+  DWARF Version:               3
+  Prologue Length:             .*
+  Minimum Instruction Length:  1
+  Initial value of 'is_stmt':  1
+  Line Base:                   -5
+  Line Range:                  14
+  Opcode Base:                 13
+
+ Opcodes:
+  Opcode 1 has 0 args
+  Opcode 2 has 1 arg
+  Opcode 3 has 1 arg
+  Opcode 4 has 1 arg
+  Opcode 5 has 1 arg
+  Opcode 6 has 0 args
+  Opcode 7 has 0 args
+  Opcode 8 has 0 args
+  Opcode 9 has 1 arg
+  Opcode 10 has 0 args
+  Opcode 11 has 0 args
+  Opcode 12 has 1 arg
+
+ The Directory Table \(offset 0x.*\):
+  .*
+
+ The File Name Table \(offset 0x.*\):
+  Entry	Dir	Time	Size	Name
+  1	1	0	0	dwarf2-line-1.s
+
+ Line Number Statements:
+  \[0x.*\]  Extended opcode 2: set Address to 0x0
+  \[0x.*\]  Special opcode 13: advance Address by 0 to 0x0 and Line by 8 to 9
+  \[0x.*\]  Special opcode 20: advance Address by 1 to 0x1 and Line by 1 to 10
+  \[0x.*\]  Advance PC by 1 to 0x2
+  \[0x.*\]  Extended opcode 1: End of Sequence
+
+
diff --git a/gas/testsuite/gas/i386/dwarf2-line-1.s b/gas/testsuite/gas/i386/dwarf2-line-1.s
new file mode 100644
index 00000000000..a2cb22e842a
--- /dev/null
+++ b/gas/testsuite/gas/i386/dwarf2-line-1.s
@@ -0,0 +1,28 @@
+        .file   "dwarf2-test.c"
+        .text
+        .section .text.startup,"ax",@progbits
+        .p2align 4
+        .globl  main
+        .type   main, @function
+main:
+        .cfi_startproc
+        nop
+        ret
+        .cfi_endproc
+        .size   main, .-main
+        .text
+
+        .section .debug_info,"",%progbits
+        .long   0x0
+        .value  0x2
+        .long   .Ldebug_abbrev0
+        .byte   0x8
+        .uleb128 0x1
+
+        .section .debug_abbrev,"",@progbits
+.Ldebug_abbrev0:
+        .uleb128 0x0    # (abbrev code)
+        .uleb128 0x0    # (abbrev code)
+        .uleb128 0x0    # (abbrev code)
+
+# No .debug_line ok even if there is a .debug_info section
diff --git a/gas/testsuite/gas/i386/dwarf2-line-2.d b/gas/testsuite/gas/i386/dwarf2-line-2.d
new file mode 100644
index 00000000000..2553fea32cd
--- /dev/null
+++ b/gas/testsuite/gas/i386/dwarf2-line-2.d
@@ -0,0 +1,48 @@
+#as: -gdwarf-2
+#readelf: -wl
+#name: DWARF .debug_line 2
+
+Raw dump of debug contents of section .z?debug_line:
+
+  Offset:                      0x0
+  Length:                      62
+  DWARF Version:               .
+  Prologue Length:             35
+  Minimum Instruction Length:  1
+  Initial value of 'is_stmt':  1
+  Line Base:                   1
+  Line Range:                  1
+  Opcode Base:                 16
+
+ Opcodes:
+  Opcode 1 has 0 args
+  Opcode 2 has 1 arg
+  Opcode 3 has 1 arg
+  Opcode 4 has 1 arg
+  Opcode 5 has 1 arg
+  Opcode 6 has 0 args
+  Opcode 7 has 0 args
+  Opcode 8 has 0 args
+  Opcode 9 has 1 arg
+  Opcode 10 has 0 args
+  Opcode 11 has 0 args
+  Opcode 12 has 1 arg
+  Opcode 13 has 0 args
+  Opcode 14 has 0 args
+  Opcode 15 has 0 args
+
+ The Directory Table is empty.
+
+ The File Name Table \(offset 0x.*\):
+  Entry	Dir	Time	Size	Name
+  1	0	0	0	file1.txt
+
+ Line Number Statements:
+  \[0x.*\]  Extended opcode 2: set Address to 0x0
+  \[0x.*\]  Advance Line by 3 to 4
+  \[0x.*\]  Copy
+  \[0x.*\]  Copy \(view 1\)
+  \[0x.*\]  Extended opcode 2: set Address to 0x0
+  \[0x.*\]  Extended opcode 1: End of Sequence
+
+
diff --git a/gas/testsuite/gas/i386/dwarf2-line-2.s b/gas/testsuite/gas/i386/dwarf2-line-2.s
new file mode 100644
index 00000000000..63dedeb6594
--- /dev/null
+++ b/gas/testsuite/gas/i386/dwarf2-line-2.s
@@ -0,0 +1,91 @@
+        .file   "dwarf2-test.c"
+        .text
+        .section .text.startup,"ax",@progbits
+        .p2align 4
+        .globl  main
+        .type   main, @function
+main:
+        .cfi_startproc
+        nop
+        ret
+        .cfi_endproc
+        .size   main, .-main
+        .text
+
+        .section .debug_info,"",%progbits
+        .long   0x0
+        .value  0x2
+        .long   .Ldebug_abbrev0
+        .byte   0x8
+        .uleb128 0x1
+
+        .section .debug_abbrev,"",@progbits
+.Ldebug_abbrev0:
+        .uleb128 0x0    # (abbrev code)
+        .uleb128 0x0    # (abbrev code)
+        .uleb128 0x0    # (abbrev code)
+
+# A non-empty .debug_line section is ok when not using .loc directives
+	.section .debug_line
+.Lline1_begin:
+	.4byte		.Lline1_end - .Lline1_start	/* Initial length */
+.Lline1_start:
+	.2byte		2			/* Version */
+	.4byte		.Lline1_lines - .Lline1_hdr	/* header_length */
+.Lline1_hdr:
+	.byte		1			/* Minimum insn length */
+	.byte		1			/* default_is_stmt */
+	.byte		1			/* line_base */
+ 	.byte		1			/* line_range */
+	.byte		0x10			/* opcode_base */
+
+	/* Standard lengths */
+	.byte		0
+	.byte		1
+	.byte		1
+	.byte		1
+	.byte		1
+	.byte		0
+	.byte		0
+	.byte		0
+	.byte		1
+	.byte		0
+	.byte		0
+	.byte		1
+	.byte		0
+	.byte		0
+	.byte		0
+
+	/* Include directories */
+	.byte		0
+
+	/* File names */
+	.ascii		"file1.txt\0"
+	.uleb128	0
+	.uleb128	0
+	.uleb128	0
+
+	.byte		0
+
+.Lline1_lines:
+	.byte		0	/* DW_LNE_set_address */
+	.uleb128	5
+	.byte		2
+	.4byte		.Lbegin_func_cu1
+
+	.byte		3	/* DW_LNS_advance_line */
+	.sleb128	3	/* ... to 4 */
+
+	.byte		1	/* DW_LNS_copy */
+
+	.byte		1	/* DW_LNS_copy (second time as an end-of-prologue marker) */
+
+	.byte		0	/* DW_LNE_set_address */
+	.uleb128	5
+	.byte		2
+	.4byte		.Lend_func_cu1
+
+	.byte		0	/* DW_LNE_end_of_sequence */
+	.uleb128	1
+	.byte		1
+
diff --git a/gas/testsuite/gas/i386/dwarf2-line-3.d b/gas/testsuite/gas/i386/dwarf2-line-3.d
new file mode 100644
index 00000000000..42c94c56821
--- /dev/null
+++ b/gas/testsuite/gas/i386/dwarf2-line-3.d
@@ -0,0 +1,3 @@
+#as: -gdwarf-2
+#name: DWARF .debug_line 3
+#error_output: dwarf2-line-3.l
diff --git a/gas/testsuite/gas/i386/dwarf2-line-3.l b/gas/testsuite/gas/i386/dwarf2-line-3.l
new file mode 100644
index 00000000000..c26e1fa8782
--- /dev/null
+++ b/gas/testsuite/gas/i386/dwarf2-line-3.l
@@ -0,0 +1,2 @@
+[^:]*: Assembler messages:
+[^:]*: Fatal error: duplicate .debug_line sections
diff --git a/gas/testsuite/gas/i386/dwarf2-line-3.s b/gas/testsuite/gas/i386/dwarf2-line-3.s
new file mode 100644
index 00000000000..2085ef93940
--- /dev/null
+++ b/gas/testsuite/gas/i386/dwarf2-line-3.s
@@ -0,0 +1,32 @@
+        .file   "dwarf2-test.c"
+        .text
+        .section .text.startup,"ax",@progbits
+        .p2align 4
+        .globl  main
+        .type   main, @function
+main:
+        .cfi_startproc
+        nop
+	.loc 1 1
+        ret
+        .cfi_endproc
+        .size   main, .-main
+        .text
+
+        .section .debug_info,"",%progbits
+        .long   0x0
+        .value  0x2
+        .long   .Ldebug_abbrev0
+        .byte   0x8
+        .uleb128 0x1
+
+        .section .debug_abbrev,"",@progbits
+.Ldebug_abbrev0:
+        .uleb128 0x0    # (abbrev code)
+        .uleb128 0x0    # (abbrev code)
+        .uleb128 0x0    # (abbrev code)
+
+# A non-empty .debug_line section is NOT ok when using .loc directives
+        .section .debug_line,"",@progbits
+.Ldebug_line0:
+        .byte 0x1
diff --git a/gas/testsuite/gas/i386/dwarf2-line-4.d b/gas/testsuite/gas/i386/dwarf2-line-4.d
new file mode 100644
index 00000000000..c0c85f4639f
--- /dev/null
+++ b/gas/testsuite/gas/i386/dwarf2-line-4.d
@@ -0,0 +1,46 @@
+#as: -gdwarf-2
+#readelf: -wl
+#name: DWARF .debug_line 4
+
+Raw dump of debug contents of section \.z?debug_line:
+
+  Offset:                      0x0
+  Length:                      .*
+  DWARF Version:               3
+  Prologue Length:             .*
+  Minimum Instruction Length:  1
+  Initial value of 'is_stmt':  1
+  Line Base:                   -5
+  Line Range:                  14
+  Opcode Base:                 13
+
+ Opcodes:
+  Opcode 1 has 0 args
+  Opcode 2 has 1 arg
+  Opcode 3 has 1 arg
+  Opcode 4 has 1 arg
+  Opcode 5 has 1 arg
+  Opcode 6 has 0 args
+  Opcode 7 has 0 args
+  Opcode 8 has 0 args
+  Opcode 9 has 1 arg
+  Opcode 10 has 0 args
+  Opcode 11 has 0 args
+  Opcode 12 has 1 arg
+
+ The Directory Table \(offset 0x.*\):
+  .*
+
+ The File Name Table \(offset 0x.*\):
+  Entry	Dir	Time	Size	Name
+  1	1	0	0	dwarf2-line-4.s
+
+ Line Number Statements:
+  \[0x.*\]  Extended opcode 2: set Address to 0x0
+  \[0x.*\]  Special opcode 13: advance Address by 0 to 0x0 and Line by 8 to 9
+  \[0x.*\]  Advance Line by -8 to 1
+  \[0x.*\]  Special opcode 19: advance Address by 1 to 0x1 and Line by 0 to 1
+  \[0x.*\]  Advance PC by 1 to 0x2
+  \[0x.*\]  Extended opcode 1: End of Sequence
+
+
diff --git a/gas/testsuite/gas/i386/dwarf2-line-4.s b/gas/testsuite/gas/i386/dwarf2-line-4.s
new file mode 100644
index 00000000000..89bb62d9db7
--- /dev/null
+++ b/gas/testsuite/gas/i386/dwarf2-line-4.s
@@ -0,0 +1,29 @@
+        .file   "dwarf2-test.c"
+        .text
+        .section .text.startup,"ax",@progbits
+        .p2align 4
+        .globl  main
+        .type   main, @function
+main:
+        .cfi_startproc
+        nop
+	.loc 1 1
+        ret
+        .cfi_endproc
+        .size   main, .-main
+        .text
+
+        .section .debug_info,"",%progbits
+        .long   0x0
+        .value  0x2
+        .long   .Ldebug_abbrev0
+        .byte   0x8
+        .uleb128 0x1
+
+        .section .debug_abbrev,"",@progbits
+.Ldebug_abbrev0:
+        .uleb128 0x0    # (abbrev code)
+        .uleb128 0x0    # (abbrev code)
+        .uleb128 0x0    # (abbrev code)
+
+# No .debug_line ok even if there is a .debug_info section and using .locs
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index 0a863ff3bd4..0efcc8c7c27 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -599,6 +599,11 @@ if [expr ([istarget "i*86-*-*"] ||  [istarget "x86_64-*-*"]) && [gas_32_check]]
 	run_dump_test "localpic"
 	run_dump_test "debug1"
 
+	run_dump_test "dwarf2-line-1"
+	run_dump_test "dwarf2-line-2"
+	run_dump_test "dwarf2-line-3"
+	run_dump_test "dwarf2-line-4"
+
 	run_dump_test "dw2-compress-2"
 	run_dump_test "dw2-compressed-2"
 
-- 
2.18.4

Re: BoF DWARF5 patches

[Mark Wielaard]

Hi,

On Mon, 2020-08-24 at 14:56 +0200, Mark Wielaard wrote:
> This afternoon there will be a BoF at the virtual Cauldron about
> DWARF5 and beyond. 
> https://linuxplumbersconf.org/event/7/contributions/746/
> 
> Here are some patches for GCC that I would like to discuss.
> I'll reply to them after the BoF with any comments people made.

Jeremy Bennett was nice enough to add the BoF notes to the GCC wiki: 
https://gcc.gnu.org/wiki/linuxplumbers2020#DWARF5.2FDWARF64_BoF

Cheers,

Mark

Re: BoF DWARF5 patches (25% .debug section size reduction)

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 3748 bytes --]

Hi,

I added some fixes to binutils gas to make sure that it always
generates DWARF5 style .debug_rnglists and .debug_line with
.debug_line_str which are more efficient than the older .debug_ranges
and .debug_line data.

There is also a pending patch to make it possible to always pass
--gdwarf-N to gas even if gcc generates its own .debug_info and
.debug_line sections.
https://sourceware.org/pipermail/binutils/2020-September/113220.html

Ideally we have a configure check to make sure that as accepts
--gdwarf-N for N={2,3,4,5} and that when the assembly file already
contains a .debug_info or .debug_line section as doesn't error out. I
haven't written that yet. It requires some way to create target
specific assembler (could be NOPs) to check the .debug_line creation
by as.

Then we can add --gdwarf-N to ASM_SPEC when gcc generates debuginfo
for DWARF version N. The below has part of that, but always uses
--gdwarf-5, and adds it even for targets that don't use DWARF, which
is obviously wrong. But I don't fully understand if I should express
this in the spec or just depend on some configure check conditionals.

To compare the .debug section sizes generated between the current gcc
master default (DWARF4) on x86_64 and using DWARF5 by default I am
using binutils master plus the above unapproved patch plus the
attached patch to gcc to enable DWARF5 by default, pass --gdwarf-5 to
as and adding Jakub's patch to keep the static member variables in C++
classes. It keep locview enabled for now to make the comparison more
fair.

For libstdc++.so we get a 21M file with current master and a 17M when
making DWARF5 the default. The debug sections look as follows:

master lib64/libstdc++.so.6.0.29:
[31] .debug_aranges  PROGBITS 0000000000000000 001da430 00015000 0    0 0  1
[32] .debug_info     PROGBITS 0000000000000000 001ef430 0079f7c3 0    0 0  1
[33] .debug_abbrev   PROGBITS 0000000000000000 0098ebf3 00054e1a 0    0 0  1
[34] .debug_line     PROGBITS 0000000000000000 009e3a0d 001779c0 0    0 0  1
[35] .debug_str      PROGBITS 0000000000000000 00b5b3cd 0012fbb6 1 MS 0 0  1
[36] .debug_loc      PROGBITS 0000000000000000 00c8af83 005c05b0 0    0 0  1
[37] .debug_ranges   PROGBITS 0000000000000000 0124b533 001b1140 0    0 0  1

dwarf5 lib64/libstdc++.so.6.0.29:
[32] .debug_aranges  PROGBITS 0000000000000000 001d9350 00015000 0    0 0  1
[33] .debug_info     PROGBITS 0000000000000000 001ee350 0078b3d1 0    0 0  1
[34] .debug_abbrev   PROGBITS 0000000000000000 00979721 00055972 0    0 0  1
[35] .debug_line     PROGBITS 0000000000000000 009cf093 0015c20b 0    0 0  1
[36] .debug_str      PROGBITS 0000000000000000 00b2b29e 00130b55 1 MS 0 0  1
[37] .debug_loclists PROGBITS 0000000000000000 00c5bdf3 00299d88 0    0 0  1
[38] .debug_rnglists PROGBITS 0000000000000000 00ef5b7b 0009357e 0    0 0  1
[39] .debug_line_str PROGBITS 0000000000000000 00f890f9 00001685 1 MS 0 0  1

master:
.debug_aranges  00015000 0.08M
.debug_info     0079f7c3 7.62M
.debug_abbrev   00054e1a 0.33M
.debug_line     001779c0 1.47M
.debug_str      0012fbb6 1.19M
.debug_loc      005c05b0 5.75M
.debug_ranges   001b1140 1.69M
                        18.13M

dwarf5:
.debug_aranges  00015000 0.08M
.debug_info     0078b3d1 7.54M
.debug_abbrev   00055972 0.33M
.debug_line     0015c20b 1.36M
.debug_str      00130b55 1.19M
.debug_loclists 00299d88 2.60M
.debug_rnglists 0009357e 0.58M
.debug_line_str 00001685 0.01M
                        13.69M

So the total size difference is 4.4MB with the DWARF5 loclists and
rngglists being much smaller than the DWARF5 locs and ranges, the
.debug_line section is slightly smaller because all directory/file
strings are now shared in the .debug_line_str. debug_info is also a
little bit smaller.

Cheers,

Mark

[-- Attachment #2: gcc-dwarf5.diff --]
[-- Type: text/x-diff, Size: 2646 bytes --]

diff --git a/gcc/common.opt b/gcc/common.opt
index dd68c61ae1d2..755df5445905 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3144,7 +3144,7 @@ Common Driver JoinedOrMissing Negative(gdwarf-)
 Generate debug information in default version of DWARF format.
 
 gdwarf-
-Common Driver Joined UInteger Var(dwarf_version) Init(4) Negative(gstabs)
+Common Driver Joined UInteger Var(dwarf_version) Init(5) Negative(gstabs)
 Generate debug information in DWARF v2 (or later) format.
 
 ggdb
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index bca8c856dc82..d69aa253f72b 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9057,13 +9057,14 @@ possible.
 @opindex gdwarf
 Produce debugging information in DWARF format (if that is supported).
 The value of @var{version} may be either 2, 3, 4 or 5; the default version
-for most targets is 4.  DWARF Version 5 is only experimental.
+for most targets is 5 (with the exception of vxworks and darwin which
+default to version 2).
 
 Note that with DWARF Version 2, some ports require and always
 use some non-conflicting DWARF 3 extensions in the unwind tables.
 
 Version 4 may require GDB 7.0 and @option{-fvar-tracking-assignments}
-for maximum benefit.
+for maximum benefit. Version 5 requires GDB 8.0 or higher.
 
 GCC no longer supports DWARF Version 1, which is substantially
 different than Version 2 and later.  For historical reasons, some
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 4096c0c0d69f..f3b114b7a4d9 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -29395,6 +29395,13 @@ prune_unused_types_walk (dw_die_ref die)
 	  if (die->die_perennial_p)
 	    break;
 
+	  /* For static data members, the declaration in the class is supposed
+	     to have DW_TAG_member tag in DWARF{3,4} but DW_TAG_variable in
+	     DWARF5.  DW_TAG_member will be marked, so mark even such
+	     DW_TAG_variables in DWARF5.  */
+	  if (dwarf_version >= 5 && class_scope_p (die->die_parent))
+	    break;
+
 	  /* premark_used_variables marks external variables --- don't mark
 	     them here.  But function-local externals are always considered
 	     used.  */
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 531f4e02dbdb..0eac2ba03a92 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -1882,6 +1882,11 @@ init_spec (void)
   }
 #endif
 
+  static const char dv[] = "%{g*:%{%:debug-level-gt(0):--gdwarf-5}} ";
+  obstack_grow (&obstack, dv, sizeof (dv) - 1);
+  obstack_grow0 (&obstack, asm_spec, strlen (asm_spec));
+  asm_spec = XOBFINISH (&obstack, const char *);
+
 #if defined LINK_EH_SPEC || defined LINK_BUILDID_SPEC || \
     defined LINKER_HASH_STYLE
 # ifdef LINK_BUILDID_SPEC

Re: BoF DWARF5 patches (25% .debug section size reduction)

[Jakub Jelinek]

On Wed, Sep 09, 2020 at 09:57:54PM +0200, Mark Wielaard wrote:
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -9057,13 +9057,14 @@ possible.
>  @opindex gdwarf
>  Produce debugging information in DWARF format (if that is supported).
>  The value of @var{version} may be either 2, 3, 4 or 5; the default version
> -for most targets is 4.  DWARF Version 5 is only experimental.
> +for most targets is 5 (with the exception of vxworks and darwin which
> +default to version 2).

I think in documentation we should spell these VxWorks and Darwin/Mac OS X

> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -29395,6 +29395,13 @@ prune_unused_types_walk (dw_die_ref die)
>  	  if (die->die_perennial_p)
>  	    break;
>  
> +	  /* For static data members, the declaration in the class is supposed
> +	     to have DW_TAG_member tag in DWARF{3,4} but DW_TAG_variable in
> +	     DWARF5.  DW_TAG_member will be marked, so mark even such
> +	     DW_TAG_variables in DWARF5.  */
> +	  if (dwarf_version >= 5 && class_scope_p (die->die_parent))
> +	    break;

I think to this Jason objected, so we need to figure out something else.

> --- a/gcc/gcc.c
> +++ b/gcc/gcc.c
> @@ -1882,6 +1882,11 @@ init_spec (void)
>    }
>  #endif
>  
> +  static const char dv[] = "%{g*:%{%:debug-level-gt(0):--gdwarf-5}} ";
> +  obstack_grow (&obstack, dv, sizeof (dv) - 1);
> +  obstack_grow0 (&obstack, asm_spec, strlen (asm_spec));
> +  asm_spec = XOBFINISH (&obstack, const char *);
> +
>  #if defined LINK_EH_SPEC || defined LINK_BUILDID_SPEC || \
>      defined LINKER_HASH_STYLE
>  # ifdef LINK_BUILDID_SPEC

and the above should be done in a different spot.

In particular:
 static const char *asm_options =
 "%{-target-help:%:print-asm-header()} "
 #if HAVE_GNU_AS
 /* If GNU AS is used, then convert -w (no warnings), -I, and -v
    to the assembler equivalents.  */
 "%{v} %{w:-W} %{I*} "
+ASM_DEBUG_OPTION_SPEC
 #endif
 ASM_COMPRESS_DEBUG_SPEC
 "%a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}";
and define ASM_DEBUG_OPTIONS_SPEC similarly to ASM_DEBUG_SPEC, except
that it would add something only for dwarf and only add --gdwarf-{2,3,4,5}
using dwarf-version-gt (ASM_DEBUG_SPEC would go first and only when
compiling *.s/*.S files).  Or maybe for HAVE_AS_GDWARF_5_DEBUG_FLAG
ASM_DEBUG_SPEC would never add --gdwarf2 and defer that to
ASM_DEBUG_OPTION_SPEC.

As for the test assembly, I'd say we should take
#define F void foo (void) {}
F
compile it with
gcc -S -O2 -g1 -dA -gno-as-loc-support -fno-merge-debug-strings
remove .cfi_* directives, remove the ret instruction, change @function
and @progbits to %function and %progbits, change .uleb128 to just .byte,
I think all the values should be small enough, maybe change .value to
.2byte and .long to .4byte (whatever is most portable across different
arches and gas versions), simplify (shorten) strings and adjust
sizes, and do something with the .quad directives, that is dependent on
the address size, perhaps just take those attributes out and adjust
.debug_abbrev?  Finally, remove all comments (emit them in the first case
just to better understand the debug info).

	Jakub

Re: BoF DWARF5 patches (25% .debug section size reduction)

[Jakub Jelinek]

On Thu, Sep 10, 2020 at 01:16:57PM +0200, Jakub Jelinek via Gcc-patches wrote:
> As for the test assembly, I'd say we should take
> #define F void foo (void) {}
> F
> compile it with
> gcc -S -O2 -g1 -dA -gno-as-loc-support -fno-merge-debug-strings
> remove .cfi_* directives, remove the ret instruction, change @function
> and @progbits to %function and %progbits, change .uleb128 to just .byte,
> I think all the values should be small enough, maybe change .value to
> .2byte and .long to .4byte (whatever is most portable across different
> arches and gas versions), simplify (shorten) strings and adjust
> sizes, and do something with the .quad directives, that is dependent on
> the address size, perhaps just take those attributes out and adjust
> .debug_abbrev?  Finally, remove all comments (emit them in the first case
> just to better understand the debug info).

I'm afraid it is hard to avoid the .quad or .8byte.
Here is a 64-bit address version that assembles fine by both x86_64 and
aarch64 as.
Unfortunately doesn't fail with broken gas versions with -gdwarf-2 without
the nop, so we'll need at least a nop in there.
Fortunately gcc/configure.ac already determines the right nop insn for the
target, in $insn.
So I guess what we want next is have the 32-bit version of this with .4byte
instead of .8byte and just let's try to assemble both versions, first
without -gdwarf-2 and the one that succeeds assemble again with -gdwarf-2
and check for the duplicate .debug_line sections error.
What do you think?

	.file	"a.c"
	.text
.Ltext0:
	.p2align 4
	.globl	foo
	.type	foo, %function
foo:
.LFB0:
.LM1:
	nop
.LM2:
.LFE0:
	.size	foo, .-foo
.Letext0:
	.section	.debug_info,"",%progbits
.Ldebug_info0:
	.4byte	0x46
	.2byte	0x4
	.4byte	.Ldebug_abbrev0
	.byte	0x8
	.byte	0x1
	.ascii "GNU C17\0"
	.byte	0xc
	.ascii "a.c\0"
	.ascii "/\0"
	.8byte	.Ltext0
	.8byte	.Letext0-.Ltext0
	.4byte	.Ldebug_line0
	.byte	0x2
	.ascii "foo\0"
	.byte	0x1
	.byte	0x2
	.byte	0x1
	.8byte	.LFB0
	.8byte	.LFE0-.LFB0
	.byte	0x1
	.byte	0x9c
	.byte	0
	.section	.debug_abbrev,"",%progbits
.Ldebug_abbrev0:
	.byte	0x1
	.byte	0x11
	.byte	0x1
	.byte	0x25
	.byte	0x8
	.byte	0x13
	.byte	0xb
	.byte	0x3
	.byte	0x8
	.byte	0x1b
	.byte	0x8
	.byte	0x11
	.byte	0x1
	.byte	0x12
	.byte	0x7
	.byte	0x10
	.byte	0x17
	.byte	0
	.byte	0
	.byte	0x2
	.byte	0x2e
	.byte	0
	.byte	0x3f
	.byte	0x19
	.byte	0x3
	.byte	0x8
	.byte	0x3a
	.byte	0xb
	.byte	0x3b
	.byte	0xb
	.byte	0x39
	.byte	0xb
	.byte	0x11
	.byte	0x1
	.byte	0x12
	.byte	0x7
	.byte	0x40
	.byte	0x18
	.byte	0
	.byte	0
	.byte	0
	.section	.debug_aranges,"",%progbits
	.4byte	0x2c
	.2byte	0x2
	.4byte	.Ldebug_info0
	.byte	0x8
	.byte	0
	.2byte	0
	.2byte	0
	.8byte	.Ltext0
	.8byte	.Letext0-.Ltext0
	.8byte	0
	.8byte	0
	.section	.debug_line,"",%progbits
.Ldebug_line0:
	.4byte	.LELT0-.LSLT0
.LSLT0:
	.2byte	0x4
	.4byte	.LELTP0-.LASLTP0
.LASLTP0:
	.byte	0x1
	.byte	0x1
	.byte	0x1
	.byte	0xf6
	.byte	0xf2
	.byte	0xd
	.byte	0
	.byte	0x1
	.byte	0x1
	.byte	0x1
	.byte	0x1
	.byte	0
	.byte	0
	.byte	0
	.byte	0x1
	.byte	0
	.byte	0
	.byte	0x1
	.byte	0
	.ascii "a.c\0"
	.byte	0
	.byte	0
	.byte	0
	.byte	0
.LELTP0:
	.byte	0
	.byte	0x9
	.byte	0x2
	.8byte	.LM1
	.byte	0x18
	.byte	0x5
	.byte	0x1
	.byte	0
	.byte	0x9
	.byte	0x2
	.8byte	.LM2
	.byte	0x1
	.byte	0x5
	.byte	0x1
	.byte	0
	.byte	0x9
	.byte	0x2
	.8byte	.Letext0
	.byte	0
	.byte	0x1
	.byte	0x1
.LELT0:
	.section	.debug_str,"",%progbits
	.ident	"GCC"


	Jakub

[PATCH] debug: Pass --gdwarf-N to assembler if fixed gas is detected during configure

[Jakub Jelinek]

On Thu, Sep 10, 2020 at 01:45:50PM +0200, Jakub Jelinek wrote:
> On Thu, Sep 10, 2020 at 01:16:57PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > As for the test assembly, I'd say we should take
> > #define F void foo (void) {}
> > F
> > compile it with
> > gcc -S -O2 -g1 -dA -gno-as-loc-support -fno-merge-debug-strings
> > remove .cfi_* directives, remove the ret instruction, change @function
> > and @progbits to %function and %progbits, change .uleb128 to just .byte,
> > I think all the values should be small enough, maybe change .value to
> > .2byte and .long to .4byte (whatever is most portable across different
> > arches and gas versions), simplify (shorten) strings and adjust
> > sizes, and do something with the .quad directives, that is dependent on
> > the address size, perhaps just take those attributes out and adjust
> > .debug_abbrev?  Finally, remove all comments (emit them in the first case
> > just to better understand the debug info).
> 
> I'm afraid it is hard to avoid the .quad or .8byte.
> Here is a 64-bit address version that assembles fine by both x86_64 and
> aarch64 as.
> Unfortunately doesn't fail with broken gas versions with -gdwarf-2 without
> the nop, so we'll need at least a nop in there.
> Fortunately gcc/configure.ac already determines the right nop insn for the
> target, in $insn.
> So I guess what we want next is have the 32-bit version of this with .4byte
> instead of .8byte and just let's try to assemble both versions, first
> without -gdwarf-2 and the one that succeeds assemble again with -gdwarf-2
> and check for the duplicate .debug_line sections error.
> What do you think?

Ok, here it is in patch form.
I've briefly tested it, with the older binutils I have around (no --gdwarf-N
support), with latest gas (--gdwarf-N that can be passed to as even when
compiling C/C++ etc. code and emitting .debug_line) and latest gas with Mark's fix
reverted (--gdwarf-N support, but can only pass it to as when assembling
user .s/.S files, not when compiling C/C++ etc.).
Will bootstrap/regtest (with the older binutils) later tonight.

2020-09-15  Jakub Jelinek  <jakub@redhat.com>

	* configure.ac (HAVE_AS_GDWARF_5_DEBUG_FLAG,
	HAVE_AS_WORKING_DWARF_4_FLAG): New tests.
	* gcc.c (ASM_DEBUG_DWARF_OPTION): Define.
	(ASM_DEBUG_SPEC): Use ASM_DEBUG_DWARF_OPTION instead of
	"--gdwarf2".  Use %{cond:opt1;:opt2} style.
	(ASM_DEBUG_OPTION_DWARF_OPT): Define.
	(ASM_DEBUG_OPTION_SPEC): Define.
	(asm_debug_option): New variable.
	(asm_options): Add "%(asm_debug_option)".
	(static_specs): Add asm_debug_option entry.
	(static_spec_functions): Add dwarf-version-gt.
	(debug_level_greater_than_spec_func): New function.
	* config/darwin.h (ASM_DEBUG_OPTION_SPEC): Define.
	* config/darwin9.h (ASM_DEBUG_OPTION_SPEC): Redefine.
	* config.in: Regenerated.
	* configure: Regenerated.

--- gcc/configure.ac.jj	2020-09-08 16:48:32.377900856 +0200
+++ gcc/configure.ac	2020-09-15 18:07:23.292249972 +0200
@@ -5192,6 +5192,194 @@ if test x"$insn" != x; then
   [AC_DEFINE(HAVE_AS_GDWARF2_DEBUG_FLAG, 1,
 [Define if your assembler supports the --gdwarf2 option.])])
 
+ gcc_GAS_CHECK_FEATURE([--gdwarf-5 option],
+  gcc_cv_as_gdwarf_5_flag,
+  [elf,2,36,0], [--gdwarf-5], [$insn],,
+  [AC_DEFINE(HAVE_AS_GDWARF_5_DEBUG_FLAG, 1,
+[Define if your assembler supports the --gdwarf-5 option.])])
+
+ dwarf4_debug_info_size=0x46
+ dwarf4_high_pc_form=7
+ dwarf4_debug_aranges_size=0x2c
+ dwarf4_line_sz=9
+ for dwarf4_addr_size in 8 4; do
+   conftest_s="\
+	.file	\"a.c\"
+	.text
+.Ltext0:
+	.p2align 4
+	.globl	foo
+	.type	foo, %function
+foo:
+.LFB0:
+.LM1:
+	$insn
+.LM2:
+.LFE0:
+	.size	foo, .-foo
+.Letext0:
+	.section	.debug_info,\"\",%progbits
+.Ldebug_info0:
+	.4byte	$dwarf4_debug_info_size
+	.2byte	0x4
+	.4byte	.Ldebug_abbrev0
+	.byte	0x$dwarf4_addr_size
+	.byte	0x1
+	.ascii \"GNU C17\\0\"
+	.byte	0xc
+	.ascii \"a.c\\0\"
+	.ascii \"/\\0\"
+	.${dwarf4_addr_size}byte	.Ltext0
+	.${dwarf4_addr_size}byte	.Letext0-.Ltext0
+	.4byte	.Ldebug_line0
+	.byte	0x2
+	.ascii \"foo\\0\"
+	.byte	0x1
+	.byte	0x2
+	.byte	0x1
+	.${dwarf4_addr_size}byte	.LFB0
+	.${dwarf4_addr_size}byte	.LFE0-.LFB0
+	.byte	0x1
+	.byte	0x9c
+	.byte	0
+	.section	.debug_abbrev,\"\",%progbits
+.Ldebug_abbrev0:
+	.byte	0x1
+	.byte	0x11
+	.byte	0x1
+	.byte	0x25
+	.byte	0x8
+	.byte	0x13
+	.byte	0xb
+	.byte	0x3
+	.byte	0x8
+	.byte	0x1b
+	.byte	0x8
+	.byte	0x11
+	.byte	0x1
+	.byte	0x12
+	.byte	0x$dwarf4_high_pc_form
+	.byte	0x10
+	.byte	0x17
+	.byte	0
+	.byte	0
+	.byte	0x2
+	.byte	0x2e
+	.byte	0
+	.byte	0x3f
+	.byte	0x19
+	.byte	0x3
+	.byte	0x8
+	.byte	0x3a
+	.byte	0xb
+	.byte	0x3b
+	.byte	0xb
+	.byte	0x39
+	.byte	0xb
+	.byte	0x11
+	.byte	0x1
+	.byte	0x12
+	.byte	0x$dwarf4_high_pc_form
+	.byte	0x40
+	.byte	0x18
+	.byte	0
+	.byte	0
+	.byte	0
+	.section	.debug_aranges,\"\",%progbits
+	.4byte	$dwarf4_debug_aranges_size
+	.2byte	0x2
+	.4byte	.Ldebug_info0
+	.byte	0x8
+	.byte	0
+	.2byte	0
+	.2byte	0
+	.${dwarf4_addr_size}byte	.Ltext0
+	.${dwarf4_addr_size}byte	.Letext0-.Ltext0
+	.${dwarf4_addr_size}byte	0
+	.${dwarf4_addr_size}byte	0
+	.section	.debug_line,\"\",%progbits
+.Ldebug_line0:
+	.4byte	.LELT0-.LSLT0
+.LSLT0:
+	.2byte	0x4
+	.4byte	.LELTP0-.LASLTP0
+.LASLTP0:
+	.byte	0x1
+	.byte	0x1
+	.byte	0x1
+	.byte	0xf6
+	.byte	0xf2
+	.byte	0xd
+	.byte	0
+	.byte	0x1
+	.byte	0x1
+	.byte	0x1
+	.byte	0x1
+	.byte	0
+	.byte	0
+	.byte	0
+	.byte	0x1
+	.byte	0
+	.byte	0
+	.byte	0x1
+	.byte	0
+	.ascii \"a.c\\0\"
+	.byte	0
+	.byte	0
+	.byte	0
+	.byte	0
+.LELTP0:
+	.byte	0
+	.byte	0x$dwarf4_line_sz
+	.byte	0x2
+	.${dwarf4_addr_size}byte	.LM1
+	.byte	0x18
+	.byte	0x5
+	.byte	0x1
+	.byte	0
+	.byte	0x$dwarf4_line_sz
+	.byte	0x2
+	.${dwarf4_addr_size}byte	.LM2
+	.byte	0x1
+	.byte	0x5
+	.byte	0x1
+	.byte	0
+	.byte	0x$dwarf4_line_sz
+	.byte	0x2
+	.${dwarf4_addr_size}byte	.Letext0
+	.byte	0
+	.byte	0x1
+	.byte	0x1
+.LELT0:
+	.section	.debug_str,\"\",%progbits
+	.ident	\"GCC\"
+"
+   dwarf4_success=no
+   if test $dwarf4_addr_size = 4; then
+     gcc_GAS_CHECK_FEATURE([assembly of compiler generated 32-bit .debug_line],
+      gcc_cv_as_debug_line_32_flag,
+      [elf,2,36,0], [], [$conftest_s],,
+      [success=yes])
+   else
+     gcc_GAS_CHECK_FEATURE([assembly of compiler generated 64-bit .debug_line],
+      gcc_cv_as_debug_line_64_flag,
+      [elf,2,36,0], [], [$conftest_s],,
+      [dwarf4_success=yes])
+   fi
+   if test $dwarf4_success = yes; then
+     gcc_GAS_CHECK_FEATURE([--gdwarf-4 not refusing compiler generated .debug_line],
+      gcc_cv_as_dwarf_4_debug_line_flag,
+      [elf,2,36,0], [--gdwarf-4], [$conftest_s],,
+      [AC_DEFINE(HAVE_AS_WORKING_DWARF_4_FLAG, 1,
+[Define if your assembler supports --gdwarf-4 even with compiler generated .debug_line])])
+     break
+   fi
+   dwarf4_debug_info_size=0x36
+   dwarf4_high_pc_form=6
+   dwarf4_debug_aranges_size=0x1c
+   dwarf4_line_sz=5
+ done
+
  gcc_GAS_CHECK_FEATURE([--gstabs option],
   gcc_cv_as_gstabs_flag,
   [elf,2,11,0], [--gstabs], [$insn],,
--- gcc/gcc.c.jj	2020-08-27 18:42:35.549712947 +0200
+++ gcc/gcc.c	2020-09-15 20:20:29.905707498 +0200
@@ -430,6 +430,7 @@ static const char *pass_through_libs_spe
 static const char *dumps_spec_func (int, const char **);
 static const char *greater_than_spec_func (int, const char **);
 static const char *debug_level_greater_than_spec_func (int, const char **);
+static const char *dwarf_version_greater_than_spec_func (int, const char **);
 static const char *find_fortran_preinclude_file (int, const char **);
 static char *convert_white_space (char *);
 static char *quote_spec (char *);
@@ -876,22 +877,39 @@ proper position among the other output f
 #endif /* HAVE_LD_COMPRESS_DEBUG >= 2 */
 
 /* Define ASM_DEBUG_SPEC to be a spec suitable for translating '-g'
-   to the assembler.  */
+   to the assembler, when compiling assembly sources only.  */
 #ifndef ASM_DEBUG_SPEC
+# if defined(HAVE_AS_GDWARF_5_DEBUG_FLAG) && defined(HAVE_AS_WORKING_DWARF_4_FLAG)
+/* If --gdwarf-N is supported and as can handle even compiler generated
+   .debug_line with it, supply --gdwarf-N in ASM_DEBUG_OPTION_SPEC rather
+   than in ASM_DEBUG_SPEC, so that it applies to both .s and .c etc.
+   compilations.  */
+#  define ASM_DEBUG_DWARF_OPTION ""
+# elif defined(HAVE_AS_GDWARF_5_DEBUG_FLAG)
+#  define ASM_DEBUG_DWARF_OPTION "%{%:dwarf-version-gt(4):--gdwarf-5;" \
+	"%:dwarf-version-gt(3):--gdwarf-4;"				\
+	"%:dwarf-version-gt(2):--gdwarf-3;"				\
+	":--gdwarf2}"
+# else
+#  define ASM_DEBUG_DWARF_OPTION "--gdwarf2"
+# endif
 # if defined(DBX_DEBUGGING_INFO) && defined(DWARF2_DEBUGGING_INFO) \
      && defined(HAVE_AS_GDWARF2_DEBUG_FLAG) && defined(HAVE_AS_GSTABS_DEBUG_FLAG)
 #  define ASM_DEBUG_SPEC						\
       (PREFERRED_DEBUGGING_TYPE == DBX_DEBUG				\
        ? "%{%:debug-level-gt(0):"					\
-	 "%{gdwarf*:--gdwarf2}%{!gdwarf*:%{g*:--gstabs}}}" ASM_MAP	\
+	 "%{gdwarf*:" ASM_DEBUG_DWARF_OPTION "};"			\
+	 ":%{g*:--gstabs}}" ASM_MAP					\
        : "%{%:debug-level-gt(0):"					\
-	 "%{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}}}" ASM_MAP)
+	 "%{gstabs*:--gstabs;"						\
+	 ":%{g*:" ASM_DEBUG_DWARF_OPTION "}}}" ASM_MAP)
 # else
 #  if defined(DBX_DEBUGGING_INFO) && defined(HAVE_AS_GSTABS_DEBUG_FLAG)
 #   define ASM_DEBUG_SPEC "%{g*:%{%:debug-level-gt(0):--gstabs}}" ASM_MAP
 #  endif
 #  if defined(DWARF2_DEBUGGING_INFO) && defined(HAVE_AS_GDWARF2_DEBUG_FLAG)
-#   define ASM_DEBUG_SPEC "%{g*:%{%:debug-level-gt(0):--gdwarf2}}" ASM_MAP
+#   define ASM_DEBUG_SPEC "%{g*:%{%:debug-level-gt(0):" \
+	ASM_DEBUG_DWARF_OPTION "}}" ASM_MAP
 #  endif
 # endif
 #endif
@@ -899,6 +917,32 @@ proper position among the other output f
 # define ASM_DEBUG_SPEC ""
 #endif
 
+/* Define ASM_DEBUG_OPTION_SPEC to be a spec suitable for translating '-g'
+   to the assembler when compiling all sources.  */
+#ifndef ASM_DEBUG_OPTION_SPEC
+# if defined(HAVE_AS_GDWARF_5_DEBUG_FLAG) && defined(HAVE_AS_WORKING_DWARF_4_FLAG)
+#  define ASM_DEBUG_OPTION_DWARF_OPT					\
+	"%{%:dwarf-version-gt(4):--gdwarf-5 ;"				\
+	"%:dwarf-version-gt(3):--gdwarf-4 ;"				\
+	"%:dwarf-version-gt(2):--gdwarf-3 ;"				\
+	":--gdwarf2 }"
+#  if defined(DBX_DEBUGGING_INFO) && defined(DWARF2_DEBUGGING_INFO)
+#  define ASM_DEBUG_OPTION_SPEC						\
+      (PREFERRED_DEBUGGING_TYPE == DBX_DEBUG				\
+       ? "%{%:debug-level-gt(0):"					\
+	 "%{gdwarf*:" ASM_DEBUG_OPTION_DWARF_OPT "}}" 			\
+       : "%{%:debug-level-gt(0):"					\
+	 "%{!gstabs*:%{g*:" ASM_DEBUG_OPTION_DWARF_OPT "}}}")
+# elif defined(DWARF2_DEBUGGING_INFO)
+#   define ASM_DEBUG_OPTION_SPEC "%{g*:%{%:debug-level-gt(0):" \
+	ASM_DEBUG_OPTION_DWARF_OPT "}}"
+#  endif
+# endif
+#endif
+#ifndef ASM_DEBUG_OPTION_SPEC
+# define ASM_DEBUG_OPTION_SPEC ""
+#endif
+
 /* Here is the spec for running the linker, after compiling all files.  */
 
 /* This is overridable by the target in case they need to specify the
@@ -1113,6 +1157,7 @@ proper position among the other output f
 #endif
 
 static const char *asm_debug = ASM_DEBUG_SPEC;
+static const char *asm_debug_option = ASM_DEBUG_OPTION_SPEC;
 static const char *cpp_spec = CPP_SPEC;
 static const char *cc1_spec = CC1_SPEC;
 static const char *cc1plus_spec = CC1PLUS_SPEC;
@@ -1212,6 +1257,7 @@ static const char *asm_options =
    to the assembler equivalents.  */
 "%{v} %{w:-W} %{I*} "
 #endif
+"%(asm_debug_option)"
 ASM_COMPRESS_DEBUG_SPEC
 "%a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}";
 
@@ -1608,6 +1654,7 @@ static struct spec_list static_specs[] =
 {
   INIT_STATIC_SPEC ("asm",			&asm_spec),
   INIT_STATIC_SPEC ("asm_debug",		&asm_debug),
+  INIT_STATIC_SPEC ("asm_debug_option",		&asm_debug_option),
   INIT_STATIC_SPEC ("asm_final",		&asm_final_spec),
   INIT_STATIC_SPEC ("asm_options",		&asm_options),
   INIT_STATIC_SPEC ("invoke_as",		&invoke_as),
@@ -1690,6 +1737,7 @@ static const struct spec_function static
   { "dumps",                    dumps_spec_func },
   { "gt",			greater_than_spec_func },
   { "debug-level-gt",		debug_level_greater_than_spec_func },
+  { "dwarf-version-gt",		dwarf_version_greater_than_spec_func },
   { "fortran-preinclude-file",	find_fortran_preinclude_file},
 #ifdef EXTRA_SPEC_FUNCTIONS
   EXTRA_SPEC_FUNCTIONS
@@ -10612,6 +10660,27 @@ debug_level_greater_than_spec_func (int
     return "";
 
   return NULL;
+}
+
+/* Returns "" if dwarf_version is greater than ARGV[ARGC-1].
+   Otherwise, return NULL.  */
+
+static const char *
+dwarf_version_greater_than_spec_func (int argc, const char **argv)
+{
+  char *converted;
+
+  if (argc != 1)
+    fatal_error (input_location,
+		 "wrong number of arguments to %%:dwarf-version-gt");
+
+  long arg = strtol (argv[0], &converted, 10);
+  gcc_assert (converted != argv[0]);
+
+  if (dwarf_version > arg)
+    return "";
+
+  return NULL;
 }
 
 static void
--- gcc/config/darwin.h.jj	2020-08-03 22:54:51.362532456 +0200
+++ gcc/config/darwin.h	2020-09-15 20:22:36.206955619 +0200
@@ -476,6 +476,7 @@ extern GTY(()) int darwin_ms_struct;
    debugging data.  */
 
 #define ASM_DEBUG_SPEC  "%{g*:%{%:debug-level-gt(0):%{!gdwarf*:--gstabs}}}"
+#define ASM_DEBUG_OPTION_SPEC ""
 #define ASM_FINAL_SPEC \
   "%{gsplit-dwarf:%ngsplit-dwarf is not supported on this platform} %<gsplit-dwarf"
 
--- gcc/config/darwin9.h.jj	2020-01-12 11:54:36.296415174 +0100
+++ gcc/config/darwin9.h	2020-09-15 20:23:16.629394939 +0200
@@ -41,6 +41,9 @@ along with GCC; see the file COPYING3.
 #undef  ASM_DEBUG_SPEC
 #define ASM_DEBUG_SPEC  "%{g*:%{%:debug-level-gt(0):%{gstabs:--gstabs}}}"
 
+#undef  ASM_DEBUG_OPTION_SPEC
+#define ASM_DEBUG_OPTION_SPEC	""
+
 #undef  ASM_OUTPUT_ALIGNED_COMMON
 #define ASM_OUTPUT_ALIGNED_COMMON(FILE, NAME, SIZE, ALIGN)		\
   do {									\
--- gcc/config.in.jj	2020-08-26 17:09:45.823254793 +0200
+++ gcc/config.in	2020-09-15 17:58:26.180666685 +0200
@@ -394,6 +394,12 @@
 #endif
 
 
+/* Define if your assembler supports the --gdwarf-5 option. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_AS_GDWARF_5_DEBUG_FLAG
+#endif
+
+
 /* Define if your assembler supports .gnu_attribute. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_AS_GNU_ATTRIBUTE
@@ -713,6 +719,13 @@
 #endif
 
 
+/* Define if your assembler supports --gdwarf-4 even with compiler generated
+   .debug_line */
+#ifndef USED_FOR_TARGET
+#undef HAVE_AS_WORKING_DWARF_4_FLAG
+#endif
+
+
 /* Define if your assembler supports -xbrace_comment option. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_AS_XBRACE_COMMENT_OPTION
--- gcc/configure.jj	2020-09-08 16:48:32.376900871 +0200
+++ gcc/configure	2020-09-15 18:07:28.626176276 +0200
@@ -28470,6 +28470,316 @@ $as_echo "#define HAVE_AS_GDWARF2_DEBUG_
 fi
 
 
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for --gdwarf-5 option" >&5
+$as_echo_n "checking assembler for --gdwarf-5 option... " >&6; }
+if ${gcc_cv_as_gdwarf_5_flag+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  gcc_cv_as_gdwarf_5_flag=no
+    if test $in_tree_gas = yes; then
+    if test $in_tree_gas_is_elf = yes \
+  && test $gcc_cv_gas_vers -ge `expr \( \( 2 \* 1000 \) + 36 \) \* 1000 + 0`
+  then gcc_cv_as_gdwarf_5_flag=yes
+fi
+  elif test x$gcc_cv_as != x; then
+    $as_echo "$insn" > conftest.s
+    if { ac_try='$gcc_cv_as $gcc_cv_as_flags --gdwarf-5 -o conftest.o conftest.s >&5'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }
+    then
+	gcc_cv_as_gdwarf_5_flag=yes
+    else
+      echo "configure: failed program was" >&5
+      cat conftest.s >&5
+    fi
+    rm -f conftest.o conftest.s
+  fi
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_as_gdwarf_5_flag" >&5
+$as_echo "$gcc_cv_as_gdwarf_5_flag" >&6; }
+if test $gcc_cv_as_gdwarf_5_flag = yes; then
+
+$as_echo "#define HAVE_AS_GDWARF_5_DEBUG_FLAG 1" >>confdefs.h
+
+fi
+
+
+ dwarf4_debug_info_size=0x46
+ dwarf4_high_pc_form=7
+ dwarf4_debug_aranges_size=0x2c
+ dwarf4_line_sz=9
+ for dwarf4_addr_size in 8 4; do
+   conftest_s="\
+	.file	\"a.c\"
+	.text
+.Ltext0:
+	.p2align 4
+	.globl	foo
+	.type	foo, %function
+foo:
+.LFB0:
+.LM1:
+	$insn
+.LM2:
+.LFE0:
+	.size	foo, .-foo
+.Letext0:
+	.section	.debug_info,\"\",%progbits
+.Ldebug_info0:
+	.4byte	$dwarf4_debug_info_size
+	.2byte	0x4
+	.4byte	.Ldebug_abbrev0
+	.byte	0x$dwarf4_addr_size
+	.byte	0x1
+	.ascii \"GNU C17\\0\"
+	.byte	0xc
+	.ascii \"a.c\\0\"
+	.ascii \"/\\0\"
+	.${dwarf4_addr_size}byte	.Ltext0
+	.${dwarf4_addr_size}byte	.Letext0-.Ltext0
+	.4byte	.Ldebug_line0
+	.byte	0x2
+	.ascii \"foo\\0\"
+	.byte	0x1
+	.byte	0x2
+	.byte	0x1
+	.${dwarf4_addr_size}byte	.LFB0
+	.${dwarf4_addr_size}byte	.LFE0-.LFB0
+	.byte	0x1
+	.byte	0x9c
+	.byte	0
+	.section	.debug_abbrev,\"\",%progbits
+.Ldebug_abbrev0:
+	.byte	0x1
+	.byte	0x11
+	.byte	0x1
+	.byte	0x25
+	.byte	0x8
+	.byte	0x13
+	.byte	0xb
+	.byte	0x3
+	.byte	0x8
+	.byte	0x1b
+	.byte	0x8
+	.byte	0x11
+	.byte	0x1
+	.byte	0x12
+	.byte	0x$dwarf4_high_pc_form
+	.byte	0x10
+	.byte	0x17
+	.byte	0
+	.byte	0
+	.byte	0x2
+	.byte	0x2e
+	.byte	0
+	.byte	0x3f
+	.byte	0x19
+	.byte	0x3
+	.byte	0x8
+	.byte	0x3a
+	.byte	0xb
+	.byte	0x3b
+	.byte	0xb
+	.byte	0x39
+	.byte	0xb
+	.byte	0x11
+	.byte	0x1
+	.byte	0x12
+	.byte	0x$dwarf4_high_pc_form
+	.byte	0x40
+	.byte	0x18
+	.byte	0
+	.byte	0
+	.byte	0
+	.section	.debug_aranges,\"\",%progbits
+	.4byte	$dwarf4_debug_aranges_size
+	.2byte	0x2
+	.4byte	.Ldebug_info0
+	.byte	0x8
+	.byte	0
+	.2byte	0
+	.2byte	0
+	.${dwarf4_addr_size}byte	.Ltext0
+	.${dwarf4_addr_size}byte	.Letext0-.Ltext0
+	.${dwarf4_addr_size}byte	0
+	.${dwarf4_addr_size}byte	0
+	.section	.debug_line,\"\",%progbits
+.Ldebug_line0:
+	.4byte	.LELT0-.LSLT0
+.LSLT0:
+	.2byte	0x4
+	.4byte	.LELTP0-.LASLTP0
+.LASLTP0:
+	.byte	0x1
+	.byte	0x1
+	.byte	0x1
+	.byte	0xf6
+	.byte	0xf2
+	.byte	0xd
+	.byte	0
+	.byte	0x1
+	.byte	0x1
+	.byte	0x1
+	.byte	0x1
+	.byte	0
+	.byte	0
+	.byte	0
+	.byte	0x1
+	.byte	0
+	.byte	0
+	.byte	0x1
+	.byte	0
+	.ascii \"a.c\\0\"
+	.byte	0
+	.byte	0
+	.byte	0
+	.byte	0
+.LELTP0:
+	.byte	0
+	.byte	0x$dwarf4_line_sz
+	.byte	0x2
+	.${dwarf4_addr_size}byte	.LM1
+	.byte	0x18
+	.byte	0x5
+	.byte	0x1
+	.byte	0
+	.byte	0x$dwarf4_line_sz
+	.byte	0x2
+	.${dwarf4_addr_size}byte	.LM2
+	.byte	0x1
+	.byte	0x5
+	.byte	0x1
+	.byte	0
+	.byte	0x$dwarf4_line_sz
+	.byte	0x2
+	.${dwarf4_addr_size}byte	.Letext0
+	.byte	0
+	.byte	0x1
+	.byte	0x1
+.LELT0:
+	.section	.debug_str,\"\",%progbits
+	.ident	\"GCC\"
+"
+   dwarf4_success=no
+   if test $dwarf4_addr_size = 4; then
+     { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for assembly of compiler generated 32-bit .debug_line" >&5
+$as_echo_n "checking assembler for assembly of compiler generated 32-bit .debug_line... " >&6; }
+if ${gcc_cv_as_debug_line_32_flag+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  gcc_cv_as_debug_line_32_flag=no
+    if test $in_tree_gas = yes; then
+    if test $in_tree_gas_is_elf = yes \
+  && test $gcc_cv_gas_vers -ge `expr \( \( 2 \* 1000 \) + 36 \) \* 1000 + 0`
+  then gcc_cv_as_debug_line_32_flag=yes
+fi
+  elif test x$gcc_cv_as != x; then
+    $as_echo "$conftest_s" > conftest.s
+    if { ac_try='$gcc_cv_as $gcc_cv_as_flags  -o conftest.o conftest.s >&5'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }
+    then
+	gcc_cv_as_debug_line_32_flag=yes
+    else
+      echo "configure: failed program was" >&5
+      cat conftest.s >&5
+    fi
+    rm -f conftest.o conftest.s
+  fi
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_as_debug_line_32_flag" >&5
+$as_echo "$gcc_cv_as_debug_line_32_flag" >&6; }
+if test $gcc_cv_as_debug_line_32_flag = yes; then
+  success=yes
+fi
+
+   else
+     { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for assembly of compiler generated 64-bit .debug_line" >&5
+$as_echo_n "checking assembler for assembly of compiler generated 64-bit .debug_line... " >&6; }
+if ${gcc_cv_as_debug_line_64_flag+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  gcc_cv_as_debug_line_64_flag=no
+    if test $in_tree_gas = yes; then
+    if test $in_tree_gas_is_elf = yes \
+  && test $gcc_cv_gas_vers -ge `expr \( \( 2 \* 1000 \) + 36 \) \* 1000 + 0`
+  then gcc_cv_as_debug_line_64_flag=yes
+fi
+  elif test x$gcc_cv_as != x; then
+    $as_echo "$conftest_s" > conftest.s
+    if { ac_try='$gcc_cv_as $gcc_cv_as_flags  -o conftest.o conftest.s >&5'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }
+    then
+	gcc_cv_as_debug_line_64_flag=yes
+    else
+      echo "configure: failed program was" >&5
+      cat conftest.s >&5
+    fi
+    rm -f conftest.o conftest.s
+  fi
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_as_debug_line_64_flag" >&5
+$as_echo "$gcc_cv_as_debug_line_64_flag" >&6; }
+if test $gcc_cv_as_debug_line_64_flag = yes; then
+  dwarf4_success=yes
+fi
+
+   fi
+   if test $dwarf4_success = yes; then
+     { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for --gdwarf-4 not refusing compiler generated .debug_line" >&5
+$as_echo_n "checking assembler for --gdwarf-4 not refusing compiler generated .debug_line... " >&6; }
+if ${gcc_cv_as_dwarf_4_debug_line_flag+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  gcc_cv_as_dwarf_4_debug_line_flag=no
+    if test $in_tree_gas = yes; then
+    if test $in_tree_gas_is_elf = yes \
+  && test $gcc_cv_gas_vers -ge `expr \( \( 2 \* 1000 \) + 36 \) \* 1000 + 0`
+  then gcc_cv_as_dwarf_4_debug_line_flag=yes
+fi
+  elif test x$gcc_cv_as != x; then
+    $as_echo "$conftest_s" > conftest.s
+    if { ac_try='$gcc_cv_as $gcc_cv_as_flags --gdwarf-4 -o conftest.o conftest.s >&5'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }
+    then
+	gcc_cv_as_dwarf_4_debug_line_flag=yes
+    else
+      echo "configure: failed program was" >&5
+      cat conftest.s >&5
+    fi
+    rm -f conftest.o conftest.s
+  fi
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_as_dwarf_4_debug_line_flag" >&5
+$as_echo "$gcc_cv_as_dwarf_4_debug_line_flag" >&6; }
+if test $gcc_cv_as_dwarf_4_debug_line_flag = yes; then
+
+$as_echo "#define HAVE_AS_WORKING_DWARF_4_FLAG 1" >>confdefs.h
+
+fi
+
+     break
+   fi
+   dwarf4_debug_info_size=0x36
+   dwarf4_high_pc_form=6
+   dwarf4_debug_aranges_size=0x1c
+   dwarf4_line_sz=5
+ done
+
  { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for --gstabs option" >&5
 $as_echo_n "checking assembler for --gstabs option... " >&6; }
 if ${gcc_cv_as_gstabs_flag+:} false; then :


	Jakub

Re: [PATCH] debug: Pass --gdwarf-N to assembler if fixed gas is detected during configure

[Mark Wielaard]

Hi,

On Tue, 2020-09-15 at 20:40 +0200, Jakub Jelinek wrote:
> Ok, here it is in patch form.
> I've briefly tested it, with the older binutils I have around (no --gdwarf-N
> support), with latest gas (--gdwarf-N that can be passed to as even when
> compiling C/C++ etc. code and emitting .debug_line) and latest gas with Mark's fix
> reverted (--gdwarf-N support, but can only pass it to as when assembling
> user .s/.S files, not when compiling C/C++ etc.).
> Will bootstrap/regtest (with the older binutils) later tonight.
> 
> 2020-09-15  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* configure.ac (HAVE_AS_GDWARF_5_DEBUG_FLAG,
> 	HAVE_AS_WORKING_DWARF_4_FLAG): New tests.
> 	* gcc.c (ASM_DEBUG_DWARF_OPTION): Define.
> 	(ASM_DEBUG_SPEC): Use ASM_DEBUG_DWARF_OPTION instead of
> 	"--gdwarf2".  Use %{cond:opt1;:opt2} style.
> 	(ASM_DEBUG_OPTION_DWARF_OPT): Define.
> 	(ASM_DEBUG_OPTION_SPEC): Define.
> 	(asm_debug_option): New variable.
> 	(asm_options): Add "%(asm_debug_option)".
> 	(static_specs): Add asm_debug_option entry.
> 	(static_spec_functions): Add dwarf-version-gt.
> 	(debug_level_greater_than_spec_func): New function.
> 	* config/darwin.h (ASM_DEBUG_OPTION_SPEC): Define.
> 	* config/darwin9.h (ASM_DEBUG_OPTION_SPEC): Redefine.
> 	* config.in: Regenerated.
> 	* configure: Regenerated.

I tested against the binutils-2_35-branch which will become 2.35.1 next
week. The configure tests succeed there. So I think you can change the
[elf,2,36,0] to [elf,2,35,1].

Also tested that they fail with an older binutils (2.32).

Cheers,

Mark

Re: [PATCH] debug: Pass --gdwarf-N to assembler if fixed gas is detected during configure

[Jakub Jelinek]

On Wed, Sep 16, 2020 at 02:33:03PM +0200, Mark Wielaard wrote:
> > 2020-09-15  Jakub Jelinek  <jakub@redhat.com>
> > 
> > 	* configure.ac (HAVE_AS_GDWARF_5_DEBUG_FLAG,
> > 	HAVE_AS_WORKING_DWARF_4_FLAG): New tests.
> > 	* gcc.c (ASM_DEBUG_DWARF_OPTION): Define.
> > 	(ASM_DEBUG_SPEC): Use ASM_DEBUG_DWARF_OPTION instead of
> > 	"--gdwarf2".  Use %{cond:opt1;:opt2} style.
> > 	(ASM_DEBUG_OPTION_DWARF_OPT): Define.
> > 	(ASM_DEBUG_OPTION_SPEC): Define.
> > 	(asm_debug_option): New variable.
> > 	(asm_options): Add "%(asm_debug_option)".
> > 	(static_specs): Add asm_debug_option entry.
> > 	(static_spec_functions): Add dwarf-version-gt.
> > 	(debug_level_greater_than_spec_func): New function.
> > 	* config/darwin.h (ASM_DEBUG_OPTION_SPEC): Define.
> > 	* config/darwin9.h (ASM_DEBUG_OPTION_SPEC): Redefine.
> > 	* config.in: Regenerated.
> > 	* configure: Regenerated.
> 
> I tested against the binutils-2_35-branch which will become 2.35.1 next
> week. The configure tests succeed there. So I think you can change the
> [elf,2,36,0] to [elf,2,35,1].

No problem with such a change, although it isn't that important, because
most of the people don't use in-tree builds and for out of tree builds
the actual test rather than version comparison is used instead.

	Jakub

Re: [PATCH] debug: Pass --gdwarf-N to assembler if fixed gas is detected during configure

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

Hi,

On Tue, 2020-09-15 at 20:40 +0200, Jakub Jelinek wrote:
> Ok, here it is in patch form.
> I've briefly tested it, with the older binutils I have around (no --gdwarf-N
> support), with latest gas (--gdwarf-N that can be passed to as even when
> compiling C/C++ etc. code and emitting .debug_line) and latest gas with Mark's fix
> reverted (--gdwarf-N support, but can only pass it to as when assembling
> user .s/.S files, not when compiling C/C++ etc.).
> Will bootstrap/regtest (with the older binutils) later tonight.
> 
> 2020-09-15  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* configure.ac (HAVE_AS_GDWARF_5_DEBUG_FLAG,
> 	HAVE_AS_WORKING_DWARF_4_FLAG): New tests.
> 	* gcc.c (ASM_DEBUG_DWARF_OPTION): Define.
> 	(ASM_DEBUG_SPEC): Use ASM_DEBUG_DWARF_OPTION instead of
> 	"--gdwarf2".  Use %{cond:opt1;:opt2} style.
> 	(ASM_DEBUG_OPTION_DWARF_OPT): Define.
> 	(ASM_DEBUG_OPTION_SPEC): Define.
> 	(asm_debug_option): New variable.
> 	(asm_options): Add "%(asm_debug_option)".
> 	(static_specs): Add asm_debug_option entry.
> 	(static_spec_functions): Add dwarf-version-gt.
> 	(debug_level_greater_than_spec_func): New function.
> 	* config/darwin.h (ASM_DEBUG_OPTION_SPEC): Define.
> 	* config/darwin9.h (ASM_DEBUG_OPTION_SPEC): Redefine.
> 	* config.in: Regenerated.
> 	* configure: Regenerated.

Once this is in we can more generally emit DW_FORM_line_str for
filepaths in CU DIEs for the name and comp_dir attribute. There
currently is a bit of a hack to do this in dwarf2out_early_finish, but
that only works when the assembler doesn't emit a DWARF5 .debug_line,
but gcc does it itself.

What do you think of the attached patch?

[-- Attachment #2: 0001-Output-filepath-strings-in-.debug_line_str-for-DWARF.patch --]
[-- Type: text/x-patch, Size: 6276 bytes --]

From c31667db57de62c3107a0b2a5e30fbd57a4708a3 Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mark@klomp.org>
Date: Fri, 18 Sep 2020 17:07:03 +0200
Subject: [PATCH] Output filepath strings in .debug_line_str for DWARF5

DWARF5 has a new string table specially for file paths. .debug_line
file and dir tables reference strings in .debug_line_str.  If a
.debug_line_str section is emitted then also place CU DIE file
names and comp dirs there.

gcc/ChangeLog:

	* dwarf2out.c (add_filepath_AT_string): New function.
	(asm_outputs_debug_line_str): Likewise.
	(add_filename_attribute): Likewise.
	(add_comp_dir_attribute): Call add_filepath_AT_string.
	(gen_compile_unit_die): Call add_filename_attribute for name.
	(init_sections_and_labels): Init debug_line_str_section when
	asm_outputs_debug_line_str return true.
	(dwarf2out_early_finish): Remove DW_AT_name and DW_AT_comp_dir
	hack and call add_filename_attribute for the remap_debug_filename.
---
 gcc/dwarf2out.c | 96 ++++++++++++++++++++++++++++++++-----------------
 1 file changed, 64 insertions(+), 32 deletions(-)

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 4096c0c0d69f..a43082864a75 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -3347,6 +3347,8 @@ output_asm_line_debug_info (void)
 	      || !debug_variable_location_views));
 }
 
+static bool asm_outputs_debug_line_str (void);
+
 /* Minimum line offset in a special line info. opcode.
    This value was chosen to give a reasonable range of values.  */
 #define DWARF_LINE_BASE  -10
@@ -4731,6 +4733,33 @@ reset_indirect_string (indirect_string_node **h, void *)
   return 1;
 }
 
+static inline void
+add_filepath_AT_string (dw_die_ref die, enum dwarf_attribute attr_kind,
+			const char *str)
+{
+  if (! asm_outputs_debug_line_str ())
+    add_AT_string (die, attr_kind, str);
+  else
+    {
+      dw_attr_node attr;
+      struct indirect_string_node *node;
+
+      if (!debug_line_str_hash)
+	debug_line_str_hash
+	  = hash_table<indirect_string_hasher>::create_ggc (10);
+
+      node = find_AT_string_in_table (str, debug_line_str_hash);
+      set_indirect_string (node);
+      node->form = DW_FORM_line_strp;
+
+      attr.dw_attr = attr_kind;
+      attr.dw_attr_val.val_class = dw_val_class_str;
+      attr.dw_attr_val.val_entry = NULL;
+      attr.dw_attr_val.v.val_str = node;
+      add_dwarf_attr (die, &attr);
+    }
+}
+
 /* Find out whether a string should be output inline in DIE
    or out-of-line in .debug_str section.  */
 
@@ -11839,6 +11868,29 @@ output_ranges (void)
       for -gsplit-dwarf we should use DW_FORM_strx instead.  */	\
    && !dwarf_split_debug_info)
 
+
+/* Returns TRUE if we are outputting DWARF5 and the assembler supports
+   DWARF5 .debug_line tables using .debug_line_str or we generate
+   it ourselves, except for split-dwarf which doesn't have a
+   .debug_line_str.  */
+static bool
+asm_outputs_debug_line_str (void)
+{
+  if (dwarf_version >= 5
+      && ! output_asm_line_debug_info ()
+      && DWARF5_USE_DEBUG_LINE_STR)
+    return true;
+  else
+    {
+#if defined(HAVE_AS_GDWARF_5_DEBUG_FLAG) && defined(HAVE_AS_WORKING_DWARF_4_FLAG)
+      return !dwarf_split_debug_info && dwarf_version >= 5;
+#else
+      return false;
+#endif
+    }
+}
+
+
 /* Assign .debug_rnglists indexes.  */
 
 static void
@@ -20514,6 +20566,13 @@ add_name_attribute (dw_die_ref die, const char *name_string)
     }
 }
 
+static void
+add_filename_attribute (dw_die_ref die, const char *name_string)
+{
+  if (name_string != NULL && *name_string != 0)
+    add_filepath_AT_string (die, DW_AT_name, name_string);
+}
+
 /* Generate a DW_AT_description attribute given some string value to be included
    as the value of the attribute.  */
 
@@ -20640,7 +20699,7 @@ add_comp_dir_attribute (dw_die_ref die)
 {
   const char * wd = comp_dir_string ();
   if (wd != NULL)
-    add_AT_string (die, DW_AT_comp_dir, wd);
+    add_filepath_AT_string (die, DW_AT_comp_dir, wd);
 }
 
 /* Given a tree node VALUE describing a scalar attribute ATTR (i.e. a bound, a
@@ -24482,7 +24541,7 @@ gen_compile_unit_die (const char *filename)
 
   if (filename)
     {
-      add_name_attribute (die, filename);
+      add_filename_attribute (die, filename);
       /* Don't add cwd for <built-in>.  */
       if (filename[0] != '<')
 	add_comp_dir_attribute (die);
@@ -28733,7 +28792,8 @@ init_sections_and_labels (bool early_lto_debug)
 					    SECTION_DEBUG, NULL);
       debug_str_section = get_section (DEBUG_STR_SECTION,
 				       DEBUG_STR_SECTION_FLAGS, NULL);
-      if (!dwarf_split_debug_info && !output_asm_line_debug_info ())
+      if ((!dwarf_split_debug_info && !output_asm_line_debug_info ())
+	  || asm_outputs_debug_line_str ())
 	debug_line_str_section = get_section (DEBUG_LINE_STR_SECTION,
 					      DEBUG_STR_SECTION_FLAGS, NULL);
 
@@ -32020,37 +32080,9 @@ dwarf2out_early_finish (const char *filename)
 
   /* Add the name for the main input file now.  We delayed this from
      dwarf2out_init to avoid complications with PCH.  */
-  add_name_attribute (comp_unit_die (), remap_debug_filename (filename));
+  add_filename_attribute (comp_unit_die (), remap_debug_filename (filename));
   add_comp_dir_attribute (comp_unit_die ());
 
-  /* When emitting DWARF5 .debug_line_str, move DW_AT_name and
-     DW_AT_comp_dir into .debug_line_str section.  */
-  if (!output_asm_line_debug_info ()
-      && dwarf_version >= 5
-      && DWARF5_USE_DEBUG_LINE_STR)
-    {
-      for (int i = 0; i < 2; i++)
-	{
-	  dw_attr_node *a = get_AT (comp_unit_die (),
-				    i ? DW_AT_comp_dir : DW_AT_name);
-	  if (a == NULL
-	      || AT_class (a) != dw_val_class_str
-	      || strlen (AT_string (a)) + 1 <= DWARF_OFFSET_SIZE)
-	    continue;
-
-	  if (! debug_line_str_hash)
-	    debug_line_str_hash
-	      = hash_table<indirect_string_hasher>::create_ggc (10);
-
-	  struct indirect_string_node *node
-	    = find_AT_string_in_table (AT_string (a), debug_line_str_hash);
-	  set_indirect_string (node);
-	  node->form = DW_FORM_line_strp;
-	  a->dw_attr_val.v.val_str->refcount--;
-	  a->dw_attr_val.v.val_str = node;
-	}
-    }
-
   /* With LTO early dwarf was really finished at compile-time, so make
      sure to adjust the phase after annotating the LTRANS CU DIE.  */
   if (in_lto_p)
-- 
2.18.4

Re: [PATCH] debug: Pass --gdwarf-N to assembler if fixed gas is detected during configure

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 2763 bytes --]

Hi,

On Fri, 2020-09-18 at 17:21 +0200, Mark Wielaard wrote:
> On Tue, 2020-09-15 at 20:40 +0200, Jakub Jelinek wrote:
> > Ok, here it is in patch form.
> > I've briefly tested it, with the older binutils I have around (no --gdwarf-N
> > support), with latest gas (--gdwarf-N that can be passed to as even when
> > compiling C/C++ etc. code and emitting .debug_line) and latest gas with Mark's fix
> > reverted (--gdwarf-N support, but can only pass it to as when assembling
> > user .s/.S files, not when compiling C/C++ etc.).
> > Will bootstrap/regtest (with the older binutils) later tonight.
> > 
> > 2020-09-15  Jakub Jelinek  <jakub@redhat.com>
> > 
> > 	* configure.ac (HAVE_AS_GDWARF_5_DEBUG_FLAG,
> > 	HAVE_AS_WORKING_DWARF_4_FLAG): New tests.
> > 	* gcc.c (ASM_DEBUG_DWARF_OPTION): Define.
> > 	(ASM_DEBUG_SPEC): Use ASM_DEBUG_DWARF_OPTION instead of
> > 	"--gdwarf2".  Use %{cond:opt1;:opt2} style.
> > 	(ASM_DEBUG_OPTION_DWARF_OPT): Define.
> > 	(ASM_DEBUG_OPTION_SPEC): Define.
> > 	(asm_debug_option): New variable.
> > 	(asm_options): Add "%(asm_debug_option)".
> > 	(static_specs): Add asm_debug_option entry.
> > 	(static_spec_functions): Add dwarf-version-gt.
> > 	(debug_level_greater_than_spec_func): New function.
> > 	* config/darwin.h (ASM_DEBUG_OPTION_SPEC): Define.
> > 	* config/darwin9.h (ASM_DEBUG_OPTION_SPEC): Redefine.
> > 	* config.in: Regenerated.
> > 	* configure: Regenerated.
> 
> Once this is in we can more generally emit DW_FORM_line_str for
> filepaths in CU DIEs for the name and comp_dir attribute. There
> currently is a bit of a hack to do this in dwarf2out_early_finish, but
> that only works when the assembler doesn't emit a DWARF5 .debug_line,
> but gcc does it itself.
> 
> What do you think of the attached patch?
>
> DWARF5 has a new string table specially for file paths. .debug_line
> file and dir tables reference strings in .debug_line_str.  If a
> .debug_line_str section is emitted then also place CU DIE file
> names and comp dirs there.
> 
> gcc/ChangeLog:
> 
> 	* dwarf2out.c (add_filepath_AT_string): New function.
> 	(asm_outputs_debug_line_str): Likewise.
> 	(add_filename_attribute): Likewise.
> 	(add_comp_dir_attribute): Call add_filepath_AT_string.
> 	(gen_compile_unit_die): Call add_filename_attribute for name.
> 	(init_sections_and_labels): Init debug_line_str_section when
> 	asm_outputs_debug_line_str return true.
> 	(dwarf2out_early_finish): Remove DW_AT_name and DW_AT_comp_dir
> 	hack and call add_filename_attribute for the remap_debug_filename.

On top of that, we also need the following, which makes sure the actual
compilation directory is used in a DWARF5 .debug_line directory table
(and not just a relative path).



[-- Attachment #2: 0001-debug-Make-sure-to-output-.file-0-when-generating-DW.patch --]
[-- Type: text/x-patch, Size: 2197 bytes --]

From 66b25bc0a5df06e211b48a54e3b5d33999c24fb6 Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mark@klomp.org>
Date: Tue, 6 Oct 2020 17:41:19 +0200
Subject: [PATCH] debug: Make sure to output .file 0 when generating DWARF5.

When gas outputs DWARF5 .debug_line[_str] then we have to tell it the
comp_dir and main file name for the zero entry line table. Otherwise
gas has to guess at the CU compilation directory and file.

Before a gcc -gdwarf-5 ../src/hello.c line table looked like:

Directory table:
 0     ../src (24)
 1     ../src (24)
 2     /usr/include (31)

File name table:
 0     hello.c (16),  0
 1     hello.c (16),  1
 2     stdio.h (44),  2

With this patch it looks like:

Directory table:
 0     /tmp/obj (0)
 1     ../src (24)
 2     /usr/include (31)

File name table:
 0     ../src/hello.c (9),  0
 1     hello.c (16),  1
 2     stdio.h (44),  2

gcc/ChangeLog:

	* dwarf2out.c (dwarf2out_finish): Emit .file 0 entry when
	generating DWARF5 .debug_line table through gas.
---
 gcc/dwarf2out.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index a43082864a75..399937a9f310 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -31764,6 +31764,27 @@ dwarf2out_finish (const char *filename)
   ASM_OUTPUT_LABEL (asm_out_file, debug_line_section_label);
   if (! output_asm_line_debug_info ())
     output_line_info (false);
+  else if (asm_outputs_debug_line_str ())
+    {
+      /* When gas outputs DWARF5 .debug_line[_str] then we have to
+	 tell it the comp_dir and main file name for the zero entry
+	 line table.  */
+      const char *comp_dir, *filename0;
+
+      comp_dir = comp_dir_string ();
+      if (comp_dir == NULL)
+	comp_dir = "";
+
+      filename0 = get_AT_string (comp_unit_die (), DW_AT_name);
+      if (filename0 == NULL)
+	filename0 = "";
+
+      fprintf (asm_out_file, "\t.file 0 ");
+      output_quoted_string (asm_out_file, remap_debug_filename (comp_dir));
+      fputc (' ', asm_out_file);
+      output_quoted_string (asm_out_file, remap_debug_filename (filename0));
+      fputc ('\n', asm_out_file);
+    }
 
   if (dwarf_split_debug_info && info_section_emitted)
     {
-- 
2.18.4

Re: [PATCH] debug: Pass --gdwarf-N to assembler if fixed gas is detected during configure

[Jason Merrill]

On 10/6/20 11:54 AM, Mark Wielaard wrote:
> Hi,
> 
> On Fri, 2020-09-18 at 17:21 +0200, Mark Wielaard wrote:
>> On Tue, 2020-09-15 at 20:40 +0200, Jakub Jelinek wrote:
>>> Ok, here it is in patch form.
>>> I've briefly tested it, with the older binutils I have around (no --gdwarf-N
>>> support), with latest gas (--gdwarf-N that can be passed to as even when
>>> compiling C/C++ etc. code and emitting .debug_line) and latest gas with Mark's fix
>>> reverted (--gdwarf-N support, but can only pass it to as when assembling
>>> user .s/.S files, not when compiling C/C++ etc.).
>>> Will bootstrap/regtest (with the older binutils) later tonight.
>>>
>>> 2020-09-15  Jakub Jelinek  <jakub@redhat.com>
>>>
>>> 	* configure.ac (HAVE_AS_GDWARF_5_DEBUG_FLAG,
>>> 	HAVE_AS_WORKING_DWARF_4_FLAG): New tests.
>>> 	* gcc.c (ASM_DEBUG_DWARF_OPTION): Define.
>>> 	(ASM_DEBUG_SPEC): Use ASM_DEBUG_DWARF_OPTION instead of
>>> 	"--gdwarf2".  Use %{cond:opt1;:opt2} style.
>>> 	(ASM_DEBUG_OPTION_DWARF_OPT): Define.
>>> 	(ASM_DEBUG_OPTION_SPEC): Define.
>>> 	(asm_debug_option): New variable.
>>> 	(asm_options): Add "%(asm_debug_option)".
>>> 	(static_specs): Add asm_debug_option entry.
>>> 	(static_spec_functions): Add dwarf-version-gt.
>>> 	(debug_level_greater_than_spec_func): New function.
>>> 	* config/darwin.h (ASM_DEBUG_OPTION_SPEC): Define.
>>> 	* config/darwin9.h (ASM_DEBUG_OPTION_SPEC): Redefine.
>>> 	* config.in: Regenerated.
>>> 	* configure: Regenerated.
>>
>> Once this is in we can more generally emit DW_FORM_line_str for
>> filepaths in CU DIEs for the name and comp_dir attribute. There
>> currently is a bit of a hack to do this in dwarf2out_early_finish, but
>> that only works when the assembler doesn't emit a DWARF5 .debug_line,
>> but gcc does it itself.
>>
>> What do you think of the attached patch?
>>
>> DWARF5 has a new string table specially for file paths. .debug_line
>> file and dir tables reference strings in .debug_line_str.  If a
>> .debug_line_str section is emitted then also place CU DIE file
>> names and comp dirs there.
>>
>> gcc/ChangeLog:
>>
>> 	* dwarf2out.c (add_filepath_AT_string): New function.
>> 	(asm_outputs_debug_line_str): Likewise.
>> 	(add_filename_attribute): Likewise.
>> 	(add_comp_dir_attribute): Call add_filepath_AT_string.
>> 	(gen_compile_unit_die): Call add_filename_attribute for name.
>> 	(init_sections_and_labels): Init debug_line_str_section when
>> 	asm_outputs_debug_line_str return true.
>> 	(dwarf2out_early_finish): Remove DW_AT_name and DW_AT_comp_dir
>> 	hack and call add_filename_attribute for the remap_debug_filename.
> 
> On top of that, we also need the following, which makes sure the actual
> compilation directory is used in a DWARF5 .debug_line directory table
> (and not just a relative path).

All three of these patches (Jakub's, and your two) look good to me, 
except that your add_filepath_AT_string patch is missing comments on 
some of the new functions.

Jason

Re: [PATCH] debug: Pass --gdwarf-N to assembler if fixed gas is detected during configure

[Mark Wielaard]

Hi,

On Tue, 2020-10-06 at 16:57 -0400, Jason Merrill wrote:
> All three of these patches (Jakub's, and your two) look good to me, 
> except that your add_filepath_AT_string patch is missing comments on 
> some of the new functions.

I added documentation for the two new functions missing comments before
pushing.

Thanks,

Mark

Re: BoF DWARF5 patches (25% .debug section size reduction)

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

On Thu, 2020-09-10 at 13:16 +0200, Jakub Jelinek wrote:
> On Wed, Sep 09, 2020 at 09:57:54PM +0200, Mark Wielaard wrote:
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -9057,13 +9057,14 @@ possible.
> >  @opindex gdwarf
> >  Produce debugging information in DWARF format (if that is supported).
> >  The value of @var{version} may be either 2, 3, 4 or 5; the default version
> > -for most targets is 4.  DWARF Version 5 is only experimental.
> > +for most targets is 5 (with the exception of vxworks and darwin which
> > +default to version 2).
> 
> I think in documentation we should spell these VxWorks and Darwin/Mac OS X

OK. As attached.

Are we ready to flip the default to 5?

Thanks,

Mark

[-- Attachment #2: 0001-Default-to-DWARF5.patch --]
[-- Type: text/x-patch, Size: 1940 bytes --]

From 409bd1b2c60905b0f96c94fface12154d3be4d32 Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mark@klomp.org>
Date: Tue, 29 Sep 2020 15:52:44 +0200
Subject: [PATCH] Default to DWARF5

gcc/ChangeLog:

	* common.opt (gdwarf-): Init(5).
	* doc/invoke.texi (-gdwarf): Document default to 5.
---
 gcc/common.opt      | 2 +-
 gcc/doc/invoke.texi | 7 ++++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index 292c2de694ef..d1722de80bf0 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3148,7 +3148,7 @@ Common Driver JoinedOrMissing Negative(gdwarf-)
 Generate debug information in default version of DWARF format.
 
 gdwarf-
-Common Driver Joined UInteger Var(dwarf_version) Init(4) Negative(gstabs)
+Common Driver Joined UInteger Var(dwarf_version) Init(5) Negative(gstabs)
 Generate debug information in DWARF v2 (or later) format.
 
 ggdb
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2091e0cd23b9..e6453374bcd4 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9210,14 +9210,15 @@ possible.
 @itemx -gdwarf-@var{version}
 @opindex gdwarf
 Produce debugging information in DWARF format (if that is supported).
-The value of @var{version} may be either 2, 3, 4 or 5; the default version
-for most targets is 4.  DWARF Version 5 is only experimental.
+The value of @var{version} may be either 2, 3, 4 or 5; the default
+version for most targets is 5 (with the exception of VxWorks and
+Darwin/Mac OS X which default to version 2).
 
 Note that with DWARF Version 2, some ports require and always
 use some non-conflicting DWARF 3 extensions in the unwind tables.
 
 Version 4 may require GDB 7.0 and @option{-fvar-tracking-assignments}
-for maximum benefit.
+for maximum benefit. Version 5 requires GDB 8.0 or higher.
 
 GCC no longer supports DWARF Version 1, which is substantially
 different than Version 2 and later.  For historical reasons, some
-- 
2.18.4

Re: BoF DWARF5 patches (25% .debug section size reduction)

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

On Tue, 2020-09-29 at 15:56 +0200, Mark Wielaard wrote:
> On Thu, 2020-09-10 at 13:16 +0200, Jakub Jelinek wrote:
> > On Wed, Sep 09, 2020 at 09:57:54PM +0200, Mark Wielaard wrote:
> > > --- a/gcc/doc/invoke.texi
> > > +++ b/gcc/doc/invoke.texi
> > > @@ -9057,13 +9057,14 @@ possible.
> > >  @opindex gdwarf
> > >  Produce debugging information in DWARF format (if that is supported).
> > >  The value of @var{version} may be either 2, 3, 4 or 5; the default version
> > > -for most targets is 4.  DWARF Version 5 is only experimental.
> > > +for most targets is 5 (with the exception of vxworks and darwin which
> > > +default to version 2).
> > 
> > I think in documentation we should spell these VxWorks and Darwin/Mac OS X
> 
> OK. As attached.
> 
> Are we ready to flip the default to 5?

Ping. It would be good to get this in now so that we can fix issues (if
any) with the DWARF5 support in the general bugfixing stage 3.

Thanks,

Mark

[-- Attachment #2: 0001-Default-to-DWARF5.patch --]
[-- Type: text/x-patch, Size: 1940 bytes --]

From c04727b6209ad4d52d1b9ba86873961bda0e1724 Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mark@klomp.org>
Date: Tue, 29 Sep 2020 15:52:44 +0200
Subject: [PATCH] Default to DWARF5

gcc/ChangeLog:

	* common.opt (gdwarf-): Init(5).
	* doc/invoke.texi (-gdwarf): Document default to 5.
---
 gcc/common.opt      | 2 +-
 gcc/doc/invoke.texi | 7 ++++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index 9552cebe0d6c..dd92ef1027c6 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3164,7 +3164,7 @@ Common Driver JoinedOrMissing Negative(gdwarf-)
 Generate debug information in default version of DWARF format.
 
 gdwarf-
-Common Driver Joined UInteger Var(dwarf_version) Init(4) Negative(gstabs)
+Common Driver Joined UInteger Var(dwarf_version) Init(5) Negative(gstabs)
 Generate debug information in DWARF v2 (or later) format.
 
 ggdb
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b3a2c7ce51d8..f31d6a46fff8 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9410,14 +9410,15 @@ possible.
 @itemx -gdwarf-@var{version}
 @opindex gdwarf
 Produce debugging information in DWARF format (if that is supported).
-The value of @var{version} may be either 2, 3, 4 or 5; the default version
-for most targets is 4.  DWARF Version 5 is only experimental.
+The value of @var{version} may be either 2, 3, 4 or 5; the default
+version for most targets is 5 (with the exception of VxWorks and
+Darwin/Mac OS X which default to version 2).
 
 Note that with DWARF Version 2, some ports require and always
 use some non-conflicting DWARF 3 extensions in the unwind tables.
 
 Version 4 may require GDB 7.0 and @option{-fvar-tracking-assignments}
-for maximum benefit.
+for maximum benefit. Version 5 requires GDB 8.0 or higher.
 
 GCC no longer supports DWARF Version 1, which is substantially
 different than Version 2 and later.  For historical reasons, some
-- 
2.18.4

Re: BoF DWARF5 patches (25% .debug section size reduction)

[Jakub Jelinek]

On Sun, Nov 15, 2020 at 11:41:24PM +0100, Mark Wielaard wrote:
> On Tue, 2020-09-29 at 15:56 +0200, Mark Wielaard wrote:
> > On Thu, 2020-09-10 at 13:16 +0200, Jakub Jelinek wrote:
> > > On Wed, Sep 09, 2020 at 09:57:54PM +0200, Mark Wielaard wrote:
> > > > --- a/gcc/doc/invoke.texi
> > > > +++ b/gcc/doc/invoke.texi
> > > > @@ -9057,13 +9057,14 @@ possible.
> > > >  @opindex gdwarf
> > > >  Produce debugging information in DWARF format (if that is supported).
> > > >  The value of @var{version} may be either 2, 3, 4 or 5; the default version
> > > > -for most targets is 4.  DWARF Version 5 is only experimental.
> > > > +for most targets is 5 (with the exception of vxworks and darwin which
> > > > +default to version 2).
> > > 
> > > I think in documentation we should spell these VxWorks and Darwin/Mac OS X
> > 
> > OK. As attached.
> > 
> > Are we ready to flip the default to 5?
> 
> Ping. It would be good to get this in now so that we can fix issues (if
> any) with the DWARF5 support in the general bugfixing stage 3.
> 
> Thanks,
> 
> Mark

> From c04727b6209ad4d52d1b9ba86873961bda0e1724 Mon Sep 17 00:00:00 2001
> From: Mark Wielaard <mark@klomp.org>
> Date: Tue, 29 Sep 2020 15:52:44 +0200
> Subject: [PATCH] Default to DWARF5
> 
> gcc/ChangeLog:
> 
> 	* common.opt (gdwarf-): Init(5).
> 	* doc/invoke.texi (-gdwarf): Document default to 5.

Ok for trunk.

	Jakub

Re: BoF DWARF5 patches (25% .debug section size reduction)

[Sebastian Huber]

On 15/01/2021 17:16, Jakub Jelinek via Gcc-patches wrote:

> On Sun, Nov 15, 2020 at 11:41:24PM +0100, Mark Wielaard wrote:
>> On Tue, 2020-09-29 at 15:56 +0200, Mark Wielaard wrote:
>>> On Thu, 2020-09-10 at 13:16 +0200, Jakub Jelinek wrote:
>>>> On Wed, Sep 09, 2020 at 09:57:54PM +0200, Mark Wielaard wrote:
>>>>> --- a/gcc/doc/invoke.texi
>>>>> +++ b/gcc/doc/invoke.texi
>>>>> @@ -9057,13 +9057,14 @@ possible.
>>>>>   @opindex gdwarf
>>>>>   Produce debugging information in DWARF format (if that is supported).
>>>>>   The value of @var{version} may be either 2, 3, 4 or 5; the default version
>>>>> -for most targets is 4.  DWARF Version 5 is only experimental.
>>>>> +for most targets is 5 (with the exception of vxworks and darwin which
>>>>> +default to version 2).
>>>> I think in documentation we should spell these VxWorks and Darwin/Mac OS X
>>> OK. As attached.
>>>
>>> Are we ready to flip the default to 5?
>> Ping. It would be good to get this in now so that we can fix issues (if
>> any) with the DWARF5 support in the general bugfixing stage 3.
>>
>> Thanks,
>>
>> Mark
>>  From c04727b6209ad4d52d1b9ba86873961bda0e1724 Mon Sep 17 00:00:00 2001
>> From: Mark Wielaard<mark@klomp.org>
>> Date: Tue, 29 Sep 2020 15:52:44 +0200
>> Subject: [PATCH] Default to DWARF5
>>
>> gcc/ChangeLog:
>>
>> 	* common.opt (gdwarf-): Init(5).
>> 	* doc/invoke.texi (-gdwarf): Document default to 5.
> Ok for trunk.

I noticed a build error with aarch64-rtems recently:

libtool: compile: 
/home/EB/sebastian_h/src/rtems-source-builder/rtems/build/aarch64-rtems7-gcc-0f951b3-newlib-9ad86f6-x86_64-linux-gnu-1/build/./gcc/xgcc 
-shared-libgcc 
-B/home/EB/sebastian_h/src/rtems-source-builder/rtems/build/aarch64-rtems7-gcc-0f951b3-newlib-9ad86f6-x86_64-linux-gnu-1/build/./gcc 
-nostdinc++ 
-L/home/EB/sebastian_h/src/rtems-source-builder/rtems/build/aarch64-rtems7-gcc-0f951b3-newlib-9ad86f6-x86_64-linux-gnu-1/build/aarch64-rtems7/libstdc++-v3/src 
-L/home/EB/sebastian_h/src/rtems-source-builder/rtems/build/aarch64-rtems7-gcc-0f951b3-newlib-9ad86f6-x86_64-linux-gnu-1/build/aarch64-rtems7/libstdc++-v3/src/.libs 
-L/home/EB/sebastian_h/src/rtems-source-builder/rtems/build/aarch64-rtems7-gcc-0f951b3-newlib-9ad86f6-x86_64-linux-gnu-1/build/aarch64-rtems7/libstdc++-v3/libsupc++/.libs 
-nostdinc 
-B/home/EB/sebastian_h/src/rtems-source-builder/rtems/build/aarch64-rtems7-gcc-0f951b3-newlib-9ad86f6-x86_64-linux-gnu-1/build/aarch64-rtems7/newlib/ 
-isystem 
/home/EB/sebastian_h/src/rtems-source-builder/rtems/build/aarch64-rtems7-gcc-0f951b3-newlib-9ad86f6-x86_64-linux-gnu-1/build/aarch64-rtems7/newlib/targ-include 
-isystem 
/home/EB/sebastian_h/src/rtems-source-builder/rtems/build/aarch64-rtems7-gcc-0f951b3-newlib-9ad86f6-x86_64-linux-gnu-1/gnu-mirror-gcc-0f951b3/newlib/libc/include 
-B/tmp/sh/rtems/7/aarch64-rtems7/bin/ 
-B/tmp/sh/rtems/7/aarch64-rtems7/lib/ -isystem 
/tmp/sh/rtems/7/aarch64-rtems7/include -isystem 
/tmp/sh/rtems/7/aarch64-rtems7/sys-include 
-I/home/EB/sebastian_h/src/rtems-source-builder/rtems/build/aarch64-rtems7-gcc-0f951b3-newlib-9ad86f6-x86_64-linux-gnu-1/gnu-mirror-gcc-0f951b3/libstdc++-v3/../libgcc 
-I/home/EB/sebastian_h/src/rtems-source-builder/rtems/build/aarch64-rtems7-gcc-0f951b3-newlib-9ad86f6-x86_64-linux-gnu-1/build/aarch64-rtems7/libstdc++-v3/include/aarch64-rtems7 
-I/home/EB/sebastian_h/src/rtems-source-builder/rtems/build/aarch64-rtems7-gcc-0f951b3-newlib-9ad86f6-x86_64-linux-gnu-1/build/aarch64-rtems7/libstdc++-v3/include 
-I/home/EB/sebastian_h/src/rtems-source-builder/rtems/build/aarch64-rtems7-gcc-0f951b3-newlib-9ad86f6-x86_64-linux-gnu-1/gnu-mirror-gcc-0f951b3/libstdc++-v3/libsupc++ 
-std=gnu++11 -fno-implicit-templates -Wall -Wextra -Wwrite-strings 
-Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections 
-fdata-sections -frandom-seed=cxx11-ios_failure.lo -g -O2 -g0 -c 
cxx11-ios_failure-lt.s -o cxx11-ios_failure.o
cxx11-ios_failure-lt.s: Assembler messages:
cxx11-ios_failure-lt.s:38443: Error: file number less than one

This is the related code:

.Ldebug_line0:
     .file 0 
"/tmp/sh/b-gcc-git-aarch64-rtems6/aarch64-rtems6/libstdc++-v3/src/c++11" 
"/home/EB/sebastian_h/src/gcc/libstdc++-v3/src/c++11/cxx11-ios_failure.cc"
     .section    .debug_str,"MS",@progbits,1

I am not sure if this is related to the change:

commit 3804e937b0e252a7e42632fe6d9f898f1851a49c
Author:     Mark Wielaard <mark@klomp.org>
AuthorDate: Tue Sep 29 15:52:44 2020 +0200
Commit:     Mark Wielaard <mark@klomp.org>
CommitDate: Sun Jan 17 01:36:39 2021 +0100

     Default to DWARF5

     gcc/ChangeLog:

             * common.opt (gdwarf-): Init(5).
             * doc/invoke.texi (-gdwarf): Document default to 5.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: BoF DWARF5 patches (25% .debug section size reduction)

[Mark Wielaard]

> On 15/01/2021 17:16, Jakub Jelinek via Gcc-patches wrote:
> > On Sun, Nov 15, 2020 at 11:41:24PM +0100, Mark Wielaard wrote:
> >> From: Mark Wielaard<mark@klomp.org>
> >> Date: Tue, 29 Sep 2020 15:52:44 +0200
> >> Subject: [PATCH] Default to DWARF5
> >>
> >> gcc/ChangeLog:
> >>
> >> 	* common.opt (gdwarf-): Init(5).
> >> 	* doc/invoke.texi (-gdwarf): Document default to 5.
> > Ok for trunk.
> 
> I noticed a build error with aarch64-rtems recently:
> [...]
> -fdata-sections -frandom-seed=cxx11-ios_failure.lo -g -O2 -g0 -c 
> cxx11-ios_failure-lt.s -o cxx11-ios_failure.o
> cxx11-ios_failure-lt.s: Assembler messages:
> cxx11-ios_failure-lt.s:38443: Error: file number less than one
> 
> This is the related code:
> 
> .Ldebug_line0:
>      .file 0 
> "/tmp/sh/b-gcc-git-aarch64-rtems6/aarch64-rtems6/libstdc++-
> v3/src/c++11" 
> "/home/EB/sebastian_h/src/gcc/libstdc++-v3/src/c++11/cxx11-
> ios_failure.cc"
>      .section    .debug_str,"MS",@progbits,1
> 
> I am not sure if this is related to the change

It was, sorry. I thought I had tested with both old and new binutils,
but apparently I messed up and didn't properly test with new binutils.

This is tracked as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98708
and Jakub pushed a workaround:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563744.html

Cheers,

Mark

Re: BoF DWARF5 patches (25% .debug section size reduction)

[Jeff Law]

On 9/29/20 7:56 AM, Mark Wielaard wrote:
> On Thu, 2020-09-10 at 13:16 +0200, Jakub Jelinek wrote:
>> On Wed, Sep 09, 2020 at 09:57:54PM +0200, Mark Wielaard wrote:
>>> --- a/gcc/doc/invoke.texi
>>> +++ b/gcc/doc/invoke.texi
>>> @@ -9057,13 +9057,14 @@ possible.
>>>  @opindex gdwarf
>>>  Produce debugging information in DWARF format (if that is supported).
>>>  The value of @var{version} may be either 2, 3, 4 or 5; the default version
>>> -for most targets is 4.  DWARF Version 5 is only experimental.
>>> +for most targets is 5 (with the exception of vxworks and darwin which
>>> +default to version 2).
>> I think in documentation we should spell these VxWorks and Darwin/Mac OS X
> OK. As attached.
>
> Are we ready to flip the default to 5?

An excellent question.  I think Jakub and/or Jason probably need to make
the call on this one.


Jeff