Hi Aaron,
On Thu, May 14, 2026 at 06:07:55PM -0400, Aaron Merey wrote:
> Prior to commit d4b0848b ("libdw: dwarf_getsrcfiles should not imply
> dwarf_getsrclines") debug_str_offset was initialized with a default
> value of 0. This default initialization was removed as part of the
> refactor introduced in d4b0848b.
>
> Restore debug_str_offset's default initialization to 0. For a
> well-formed binary, it wasn't possible to use debug_str_offset
> uninitialized. The value is only relevant for line headers using
> NVIDIA's CUBIN extension, in which case the real offset was always
> stored in debug_str_offset before use. However it's possible for a
> malformed binary to cause uninitialized use and static analyzers
> may complain about this.
Yeah, I can see how this might go wrong if there was no str_offset at
the end of the header, but there were still DW_LNE_NVIDIA opcodes
used. dwarf_linefunctionname would do a sanity check, so I don't think
this would cause a real issue (at most you would get a random string
back, but not an invalid one). Always initializing it would at least
take away to randomness.
> Signed-off-by: Aaron Merey <[email protected]>
> ---
> libdw/dwarf_getsrclines.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/libdw/dwarf_getsrclines.c b/libdw/dwarf_getsrclines.c
> index b3fe7cc8..35215119 100644
> --- a/libdw/dwarf_getsrclines.c
> +++ b/libdw/dwarf_getsrclines.c
> @@ -279,6 +279,10 @@ read_line_header (Dwarf *dbg, unsigned address_size,
> /* The opcode base. */
> lh->opcode_base = *linep++;
>
> + /* If the line header uses the NVIDIA CUBIN extension, debug_str_offset's
> + actual value will be read from the last 4 bytes of the header. */
> + lh->debug_str_offset = 0;
> +
> /* Remember array with the standard opcode length (-1 to account for
> the opcode with value zero not being mentioned). */
> lh->standard_opcode_lengths = linep - 1;
That seems to be the right place to initialize it.
Thanks,
Mark
