[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] gdb/testsuite: skip ada-valprint-error with clang

[Tom de Vries]

On 3/31/26 4:29 PM, Bratislav Filipovic wrote:
> The ada-valprint-error.exp test fails when compiled with clang due
> to a linker relocation issue in the test infrastructure, not a GDB
> bug.
> 
> The test compiles ada-valprint-error.c with nodebug flags, then
> links it with a separate DWARF .o file generated by lib/dwarf.exp.
> The C source defines:
> 
>      int buffer[] = {0, 0};
>      void *fd__global = &buffer;
> 
> This requires the linker to apply an R_X86_64_64 relocation to
> store buffer's address into fd__global.  With GCC, the linker
> correctly applies this relocation.  With clang, the linker fails
> to apply it, leaving fd__global as NULL.
> 
> Binary evidence:
> - GCC binary: fd__global = 0x4020 (correct address of buffer)
> - Clang binary: fd__global = 0x0 (NULL)
> 
> Both .o files contain the R_X86_64_64 relocation entry, but the
> final linked binary differs:
> - GCC emits fd__global in .data.rel.local section -> relocation works
> - Clang emits fd__global in .data section -> relocation fails
> 
> This appears to be a toolchain/testsuite compatibility issue when
> linking nodebug object files with separate DWARF objects.  Skip
> the test for clang to avoid false failures.
> 
> Tested on x86_64-linux-gnu with both GCC and clang.
> 
> ---
>   gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp b/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
> index f3d61e91..c23d58a8 100644
> --- a/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
> +++ b/gdb/testsuite/gdb.dwarf2/ada-valprint-error.exp
> @@ -14,6 +14,14 @@
>   # along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   load_lib dwarf.exp
>   
> +# Clang's linker fails to apply relocations when linking nodebug .o
> +# with separate DWARF .o, resulting in fd__global being NULL instead
> +# of pointing to buffer.
> +if {[test_compiler_info "clang-*"]} {
> +    unsupported "clang linker relocation issue with nodebug+DWARF linking"
> +    return
> +}

Hi,

I think it would be useful if you'd document what version of clang 
you're having this problem with.

And since it's not clear to me from your explanation whether it's a 
compiler or linker bug, perhaps linker version as well?

Also, this test-case passes for me with clang (17.0.6, 19.1.7, with ld 
2.45.0), so disabling it entirely for clang seems too intrusive.

How about printing the value of fd__global, and declaring the test-case 
unsupported if the value is nullptr?

Thanks,
- Tom

> +
>   # This test can only be run on targets which support DWARF-2 and use gas.
>   require dwarf2_support
>   

[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

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.
---
 .../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 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

[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/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>