[PATCH] dwarf2: avoid decoding .debug_line for type units

[PATCH] dwarf2: avoid decoding .debug_line for type units

[Bratislav Filipovic]

Running gdb.dwarf2/pr13961.exp with clang fails with an internal error:

  gdb/dwarf2/read.c: internal-error: decode_line_header_for_cu:
  Assertion `!cu->per_cu->is_debug_types ()' failed.

pr13961 is a legacy .S test that references a .debug_line label from
both a CU and a TU.  The assembly includes an empty .debug_line section
declaration:

  .section .debug_line,"",%progbits
.Ldebug_line0:

With gcc this results in a dummy (valid, but content-less) .debug_line
header being emitted, so GDB can build a line header and resolve file
indices.  With clang the .debug_line section can be missing/empty,
leaving the line header unset.

During symbol creation, new_symbol may then try to lazily decode the
CU-only line header while processing a type unit, which triggers the
assertion above.

Fix this by only decoding the line header for non-type units.  If no
line header is available, emit a complaint and continue without setting
the symtab rather than attempting CU-only line decoding from a TU.

Tested: gdb.dwarf2/pr13961.exp (CC_FOR_TARGET=clang)
---
 gdb/dwarf2/read.c | 27 ++++++++++++++++++---------
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 8b87d58d..2e897e65 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -15484,23 +15484,32 @@ new_symbol (struct die_info *die, struct type *type, struct dwarf2_cu *cu,
 	  if (index_cst.has_value ())
 	    {
 	      file_name_index file_index = (file_name_index) *index_cst;
-	      struct file_entry *fe;
 
-	      if (file_cu->line_header == nullptr)
+	      /* Resolve DW_AT_decl_file/DW_AT_call_file.  These attributes are
+		 indices into the file-name table, which lives in the unit's
+		 decoded .debug_line header.
+		 decode_line_header_for_cu is CU-only and asserts on debug_types.
+		 For type units, the TU setup code runs before processing child
+		 DIEs, so if line_header is still nullptr here it means there is no
+		 usable line table for this unit.  */
+	      if (file_cu->line_header == nullptr
+		  && !file_cu->per_cu->is_debug_types ())
 		{
 		  file_and_directory fnd (nullptr, nullptr);
 		  decode_line_header_for_cu (file_cu->dies, file_cu, fnd);
 		}
 
 	      if (file_cu->line_header != nullptr)
-		fe = file_cu->line_header->file_name_at (file_index);
-	      else
-		fe = NULL;
-
-	      if (fe == NULL)
-		complaint (_("file index out of range"));
+		{
+		  if (file_entry *fe
+		      = file_cu->line_header->file_name_at (file_index);
+		      fe != nullptr)
+		    sym->set_symtab (fe->symtab (*file_cu));
+		  else
+		    complaint (_("file index out of range"));
+		}
 	      else
-		sym->set_symtab (fe->symtab (*file_cu));
+		complaint (_("missing .debug_line information to resolve file index"));
 	    }
 	}
 
-- 
2.43.0

RE: [PING][PATCH] dwarf2: avoid decoding .debug_line for type units

[Filipovic, Bratislav]

[AMD Official Use Only - AMD Internal Distribution Only]

PING
Can someone take a look at this?

Regards Bratislav

-----Original Message-----
From: Filipovic, Bratislav <Bratislav.Filipovic@amd.com>
Sent: Wednesday, March 18, 2026 2:36 PM
To: gdb-patches@sourceware.org
Cc: simon.marchi@efficios.com; Filipovic, Bratislav <Bratislav.Filipovic@amd.com>
Subject: [PATCH] dwarf2: avoid decoding .debug_line for type units

Running gdb.dwarf2/pr13961.exp with clang fails with an internal error:

  gdb/dwarf2/read.c: internal-error: decode_line_header_for_cu:
  Assertion `!cu->per_cu->is_debug_types ()' failed.

pr13961 is a legacy .S test that references a .debug_line label from both a CU and a TU.  The assembly includes an empty .debug_line section
declaration:

  .section .debug_line,"",%progbits
.Ldebug_line0:

With gcc this results in a dummy (valid, but content-less) .debug_line header being emitted, so GDB can build a line header and resolve file indices.  With clang the .debug_line section can be missing/empty, leaving the line header unset.

During symbol creation, new_symbol may then try to lazily decode the CU-only line header while processing a type unit, which triggers the assertion above.

Fix this by only decoding the line header for non-type units.  If no line header is available, emit a complaint and continue without setting the symtab rather than attempting CU-only line decoding from a TU.

Tested: gdb.dwarf2/pr13961.exp (CC_FOR_TARGET=clang)
---
 gdb/dwarf2/read.c | 27 ++++++++++++++++++---------
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 8b87d58d..2e897e65 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -15484,23 +15484,32 @@ new_symbol (struct die_info *die, struct type *type, struct dwarf2_cu *cu,
          if (index_cst.has_value ())
            {
              file_name_index file_index = (file_name_index) *index_cst;
-             struct file_entry *fe;

-             if (file_cu->line_header == nullptr)
+             /* Resolve DW_AT_decl_file/DW_AT_call_file.  These attributes are
+                indices into the file-name table, which lives in the unit's
+                decoded .debug_line header.
+                decode_line_header_for_cu is CU-only and asserts on debug_types.
+                For type units, the TU setup code runs before processing child
+                DIEs, so if line_header is still nullptr here it means there is no
+                usable line table for this unit.  */
+             if (file_cu->line_header == nullptr
+                 && !file_cu->per_cu->is_debug_types ())
                {
                  file_and_directory fnd (nullptr, nullptr);
                  decode_line_header_for_cu (file_cu->dies, file_cu, fnd);
                }

              if (file_cu->line_header != nullptr)
-               fe = file_cu->line_header->file_name_at (file_index);
-             else
-               fe = NULL;
-
-             if (fe == NULL)
-               complaint (_("file index out of range"));
+               {
+                 if (file_entry *fe
+                     = file_cu->line_header->file_name_at (file_index);
+                     fe != nullptr)
+                   sym->set_symtab (fe->symtab (*file_cu));
+                 else
+                   complaint (_("file index out of range"));
+               }
              else
-               sym->set_symtab (fe->symtab (*file_cu));
+               complaint (_("missing .debug_line information to resolve file
+index"));
            }
        }

--
2.43.0

Re: [PATCH] testsuite: ada-valprint-error relocation issue

[Bratislav Filipovic]

Ping.

Re: [PATCH] testsuite: ada-valprint-error relocation issue

[Tom de Vries]

On 4/16/26 4:10 PM, Bratislav Filipovic wrote:
> Ping.

I've pushed this:
...
$ git show -s --pretty=fuller 5ae26f34ef5ac863203d63fffc968d63e823172f
commit 5ae26f34ef5ac863203d63fffc968d63e823172f
Author:     Bratislav Filipovic <bfilipov@amd.com>
AuthorDate: Fri Apr 3 08:11:02 2026 +0200
Commit:     Tom de Vries <tdevries@suse.de>
CommitDate: Fri Apr 3 08:11:02 2026 +0200

     testsuite: ada-valprint-error relocation issue
...
as mentioned here ( 
https://sourceware.org/pipermail/gdb-patches/2026-April/226315.html ).

Thanks,
- Tom

Re: [PATCH] testsuite: ada-valprint-error relocation issue

[Tom de Vries]

On 4/2/26 3:12 PM, Filipovic, Bratislav wrote:
> Yes, blanket assignment. About pushing, I was told to ask you to push it since I've only recently started contributing and
> I don't have write-after-approval access.

Hi,

I've pushed this, with the tag below.

Thanks,
- Tom

Approved-By: Tom de Vries <tdevries@suse.de>

RE: [PATCH] testsuite: ada-valprint-error relocation issue

[Filipovic, Bratislav]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Tom,

Yes, blanket assignment. About pushing, I was told to ask you to push it since I've only recently started contributing and
I don't have write-after-approval access.

Regards Bratislav


-----Original Message-----
From: Tom de Vries <tdevries@suse.de>
Sent: Wednesday, April 1, 2026 8:12 PM
To: Filipovic, Bratislav <Bratislav.Filipovic@amd.com>
Cc: gdb-patches@sourceware.org; simon.marchi@efficios.com
Subject: Re: [PATCH] testsuite: ada-valprint-error relocation issue

[You don't often get email from tdevries@suse.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.


On 4/1/26 4:10 PM, Bratislav Filipovic wrote:
> The ada-valprint-error.exp test links a nodebug .o file with a
> separate DWARF .o file generated by lib/dwarf.exp. This requires the
> linker to apply relocations for initialized pointers in the .data section.
>
> Some clang + linker combinations fail to apply these relocations,
> leaving fd__global as NULL instead of pointing to buffer. This causes
> the test to print null instead of the expected error message.
>
> Binary evidence from .comment section confirms which compiler and
> linker were used. Testing shows:
> - GCC 13 + GNU ld 2.42: PASS
> - clang 20 + GNU ld 2.42: FAIL
> - clang 22 + ld.lld 22: FAIL
> - clang 17/19 + GNU ld 2.45.0: PASS
>
> The failure is a linker limitation when handling this specific
> relocation pattern, not a GDB bug. Document this in the test file to
> help users understand why the test may fail with certain toolchains.

Hi,

the patch LGTM, but I'm wondering, do you have a copyright assignment, or are you covered by an AMD blanket assignment perhaps?

Thanks,
- Tom

> ---
>   .../gdb.dwarf2/ada-valprint-error.exp         | 21 +++++++++++++++++++
>   1 file changed, 21 insertions(+)
>
> diff --git a/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
> b/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
> index f3d61e91..00e737bc 100644
> --- a/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
> +++ b/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
> @@ -107,6 +107,27 @@ if { [prepare_for_testing ${testfile}.exp ${testfile} \
>       return -1
>   }
>
> +# Note: This test may fail with certain clang + linker combinations #
> +Specifically, clang + ld.lld can fail to apply relocations when
> +linking # nodebug .o with separate DWARF .o, leaving fd__global as
> +NULL instead # of pointing to buffer. The failure is a linker limitation, not a GDB bug.
> +#
> +# Known to fail: clang 20/22 + GNU ld 2.42, clang 22 + ld.lld 22 #
> +Known to pass: GCC + GNU ld, clang 17/19 + GNU ld 2.45.0 set
> +unsupported 0 gdb_test_multiple "print /x fd__global" "check
> +fd__global value" {
> +    -re -wrap "@0x0: 0x0" {
> +     set unsupported 1
> +    }
> +    -re -wrap "" {
> +     pass $gdb_test_name
> +    }
> +}
> +if {$unsupported} {
> +    unsupported "linker failed to apply relocation for fd__global"
> +    return
> +}
> +
>   gdb_test_no_output "set language ada"
>
>   gdb_test "print fd.global" \

Re: [PATCH] testsuite: ada-valprint-error relocation issue

[Tom de Vries]

On 4/1/26 4:10 PM, Bratislav Filipovic wrote:
> The ada-valprint-error.exp test links a nodebug .o file with a separate
> DWARF .o file generated by lib/dwarf.exp. This requires the linker to
> apply relocations for initialized pointers in the .data section.
> 
> Some clang + linker combinations fail to apply these relocations,
> leaving fd__global as NULL instead of pointing to buffer. This causes
> the test to print null instead of the expected error message.
> 
> Binary evidence from .comment section confirms which compiler and
> linker were used. Testing shows:
> - GCC 13 + GNU ld 2.42: PASS
> - clang 20 + GNU ld 2.42: FAIL
> - clang 22 + ld.lld 22: FAIL
> - clang 17/19 + GNU ld 2.45.0: PASS
> 
> The failure is a linker limitation when handling this specific
> relocation pattern, not a GDB bug. Document this in the test file
> to help users understand why the test may fail with certain toolchains.

Hi,

the patch LGTM, but I'm wondering, do you have a copyright assignment, 
or are you covered by an AMD blanket assignment perhaps?

Thanks,
- Tom

> ---
>   .../gdb.dwarf2/ada-valprint-error.exp         | 21 +++++++++++++++++++
>   1 file changed, 21 insertions(+)
> 
> diff --git a/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp b/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
> index f3d61e91..00e737bc 100644
> --- a/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
> +++ b/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
> @@ -107,6 +107,27 @@ if { [prepare_for_testing ${testfile}.exp ${testfile} \
>       return -1
>   }
>   
> +# Note: This test may fail with certain clang + linker combinations
> +# Specifically, clang + ld.lld can fail to apply relocations when linking
> +# nodebug .o with separate DWARF .o, leaving fd__global as NULL instead
> +# of pointing to buffer. The failure is a linker limitation, not a GDB bug.
> +#
> +# Known to fail: clang 20/22 + GNU ld 2.42, clang 22 + ld.lld 22
> +# Known to pass: GCC + GNU ld, clang 17/19 + GNU ld 2.45.0
> +set unsupported 0
> +gdb_test_multiple "print /x fd__global" "check fd__global value" {
> +    -re -wrap "@0x0: 0x0" {
> +	set unsupported 1
> +    }
> +    -re -wrap "" {
> +	pass $gdb_test_name
> +    }
> +}
> +if {$unsupported} {
> +    unsupported "linker failed to apply relocation for fd__global"
> +    return
> +}
> +
>   gdb_test_no_output "set language ada"
>   
>   gdb_test "print fd.global" \

[PATCH] testsuite: ada-valprint-error relocation issue

[Bratislav Filipovic]

The ada-valprint-error.exp test links a nodebug .o file with a separate
DWARF .o file generated by lib/dwarf.exp. This requires the linker to
apply relocations for initialized pointers in the .data section.

Some clang + linker combinations fail to apply these relocations,
leaving fd__global as NULL instead of pointing to buffer. This causes
the test to print null instead of the expected error message.

Binary evidence from .comment section confirms which compiler and
linker were used. Testing shows:
- GCC 13 + GNU ld 2.42: PASS
- clang 20 + GNU ld 2.42: FAIL
- clang 22 + ld.lld 22: FAIL
- clang 17/19 + GNU ld 2.45.0: PASS

The failure is a linker limitation when handling this specific
relocation pattern, not a GDB bug. Document this in the test file
to help users understand why the test may fail with certain toolchains.
---
 .../gdb.dwarf2/ada-valprint-error.exp         | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp b/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
index f3d61e91..00e737bc 100644
--- a/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
+++ b/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
@@ -107,6 +107,27 @@ if { [prepare_for_testing ${testfile}.exp ${testfile} \
     return -1
 }
 
+# Note: This test may fail with certain clang + linker combinations
+# Specifically, clang + ld.lld can fail to apply relocations when linking
+# nodebug .o with separate DWARF .o, leaving fd__global as NULL instead
+# of pointing to buffer. The failure is a linker limitation, not a GDB bug.
+#
+# Known to fail: clang 20/22 + GNU ld 2.42, clang 22 + ld.lld 22
+# Known to pass: GCC + GNU ld, clang 17/19 + GNU ld 2.45.0
+set unsupported 0
+gdb_test_multiple "print /x fd__global" "check fd__global value" {
+    -re -wrap "@0x0: 0x0" {
+	set unsupported 1
+    }
+    -re -wrap "" {
+	pass $gdb_test_name
+    }
+}
+if {$unsupported} {
+    unsupported "linker failed to apply relocation for fd__global"
+    return
+}
+
 gdb_test_no_output "set language ada"
 
 gdb_test "print fd.global" \
-- 
2.43.0

Re: [PATCH] testsuite: ada-valprint-error relocation issue

[Tom de Vries]

On 4/1/26 12:33 PM, Bratislav Filipovic wrote:
> The ada-valprint-error.exp test links a nodebug .o file with a separate
> DWARF .o file generated by lib/dwarf.exp. This requires the linker to
> apply relocations for initialized pointers in the .data section.
> 
> Some clang + linker combinations fail to apply these relocations,
> leaving fd__global as NULL instead of pointing to buffer. This causes
> the test to print null instead of the expected error message.
> 
> Binary evidence from .comment section confirms which compiler and
> linker were used. Testing shows:
> - GCC 13 + GNU ld 2.42: PASS
> - clang 20 + GNU ld 2.42: FAIL
> - clang 22 + ld.lld 22: FAIL
> - clang 17/19 + GNU ld 2.45.0: PASS
> 
> The failure is a linker limitation when handling this specific
> relocation pattern, not a GDB bug. Document this in the test file
> to help users understand why the test may fail with certain toolchains.
> ---
> Thanks for review Tom. I changed it per your suggestions. It seems to
> fail only for some combinations of clang + linker.
> 

Hi,

thanks for the update, I have a few comments.

First of all, the commit needs whitespace fixes, as mentioned by the 
pre-commit check:
...
$ pre-commit run --all-files check-whitespace
check-whitespace.........................................................Failed
- hook id: check-whitespace
- exit code: 2

gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp:119: indent with spaces.
+        unsupported "linker failed to apply relocation for fd__global"
gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp:120: indent with spaces.
+        return
gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp:123: indent with spaces.
+        pass $gdb_test_name

$
...

[ Consider installing pre-commit on your system (to be able to run it 
manually), and also installing pre-commit hooks in your git repo (to let 
git run it automatically). ]

>   gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp | 17 +++++++++++++++++
>   1 file changed, 17 insertions(+)
> 
> diff --git a/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp b/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
> index f3d61e91..b72682f7 100644
> --- a/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
> +++ b/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
> @@ -107,6 +107,23 @@ if { [prepare_for_testing ${testfile}.exp ${testfile} \
>       return -1
>   }
>   
> +# Note: This test may fail with certain clang + linker combinations
> +# Specifically, clang + ld.lld can fail to apply relocations when linking
> +# nodebug .o with separate DWARF .o, leaving fd__global as NULL instead
> +# of pointing to buffer. The failure is a linker limitation, not a GDB bug.
> +#
> +# Known to fail: clang 20/22 + GNU ld 2.42, clang 22 + ld.lld 22
> +# Known to pass: GCC + GNU ld, clang 17/19 + GNU ld 2.45.0
> +gdb_test_multiple "print /x fd__global" "check fd__global value" {
> +    -re -wrap "@0x0: 0x0" {
> +        unsupported "linker failed to apply relocation for fd__global"
> +        return
> +    }

FWIW, I usually try to keep non-local Tcl control flow (like return or 
break/continue not contained in a local loop) out of the regexp clauses. 
  I think this may have been necessary at some point, so I got in the 
habit of doing so.  I'm not sure if that's still necessary, but I still 
think it's a somewhat cleaner style.

The pattern I use instead is:
...
set unsupported 0
gdb_test_multiple ... {
     -re -wrap ... {
	set unsupported 1
     }
     ...
}
if {$unsupported} {
     unsupported "linker failed to apply relocation for fd__global"
     return
}
...

Anyway, it's not necessary to change this.

> +    -re -wrap "= $hex" {
> +        pass $gdb_test_name
> +    }
> +}
> +

I applied the patch, ran the test-case, and ran into:
...
(gdb) print /x fd__global^M
$1 = (fd__ints_doubled &) @0x404020: 0x404020 <buffer>^M
(gdb) FAIL: gdb.dwarf2/ada-valprint-error.exp: check fd__global value
...

The regexp doesn't match.

This can easily be fixed by simply using:
...
     -re -wrap "" {
         pass $gdb_test_name
     }
...

Thanks,
- Tom

>   gdb_test_no_output "set language ada"
>   
>   gdb_test "print fd.global" \

[PATCH] testsuite: ada-valprint-error relocation issue

[Bratislav Filipovic]

The ada-valprint-error.exp test links a nodebug .o file with a separate
DWARF .o file generated by lib/dwarf.exp. This requires the linker to
apply relocations for initialized pointers in the .data section.

Some clang + linker combinations fail to apply these relocations,
leaving fd__global as NULL instead of pointing to buffer. This causes
the test to print null instead of the expected error message.

Binary evidence from .comment section confirms which compiler and
linker were used. Testing shows:
- GCC 13 + GNU ld 2.42: PASS
- clang 20 + GNU ld 2.42: FAIL
- clang 22 + ld.lld 22: FAIL
- clang 17/19 + GNU ld 2.45.0: PASS

The failure is a linker limitation when handling this specific
relocation pattern, not a GDB bug. Document this in the test file
to help users understand why the test may fail with certain toolchains.
---
Thanks for review Tom. I changed it per your suggestions. It seems to 
fail only for some combinations of clang + linker.

 gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp b/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
index f3d61e91..b72682f7 100644
--- a/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
+++ b/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
@@ -107,6 +107,23 @@ if { [prepare_for_testing ${testfile}.exp ${testfile} \
     return -1
 }
 
+# Note: This test may fail with certain clang + linker combinations
+# Specifically, clang + ld.lld can fail to apply relocations when linking
+# nodebug .o with separate DWARF .o, leaving fd__global as NULL instead
+# of pointing to buffer. The failure is a linker limitation, not a GDB bug.
+#
+# Known to fail: clang 20/22 + GNU ld 2.42, clang 22 + ld.lld 22
+# Known to pass: GCC + GNU ld, clang 17/19 + GNU ld 2.45.0
+gdb_test_multiple "print /x fd__global" "check fd__global value" {
+    -re -wrap "@0x0: 0x0" {
+        unsupported "linker failed to apply relocation for fd__global"
+        return
+    }
+    -re -wrap "= $hex" {
+        pass $gdb_test_name
+    }
+}
+
 gdb_test_no_output "set language ada"
 
 gdb_test "print fd.global" \
-- 
2.43.0