Bug 2166796

Summary:	gdb gives a weird error about potentially wrong DWARF information in jq debuginfo (DWARF-2 expression error: DW_OP_GNU_uninit must always be the very last op.)
Product:	[Fedora] Fedora	Reporter:	Gabriel Ravier <gabravier>
Component:	gdb	Assignee:	Kevin Buettner <kevinb>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	37	CC:	ahajkova, fweimer, guinevere, jan, keiths, kevinb, mcermak, mjw, pmuldoon, sergiodj
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-08-02 16:09:49 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Gabriel Ravier 2023-02-03 01:14:45 UTC

Description of problem:
gdb gives an odd error when trying to watch some somewhat complex expressions while debugging the jq program

Version-Release number of selected component (if applicable):
gdb: gdb-12.1-7.fc37.src.rpm
jq: jq-1.6-14.fc37.src.rpm
jq-debuginfo: jq-1.6-14.fc37.src.rpm
jq-debugsource: jq-1.6-14.fc37.src.rpm

How reproducible:
Always

Steps to Reproduce:
1. Run the following command (when gdb asks to make the breakpoint pending on future shared library load, say yes):

gdb jq -ex 'b src/util.c:415' -ex 'r </dev/null' -ex 'watch value.u.ptr'

(Note: src/util.c:415 here corresponds to the 5th line of the `jq_util_input_next_input` containing `if (state->parser == NULL)`, if you're trying to reproduce this on a different version of jq where the line numbers have likely changed)

Actual results:
GDB outputs the following when trying to evaluate the `watch` command:
DWARF-2 expression error: DW_OP_GNU_uninit must always be the very last op.

Expected results:
GDB either succeeds in creating the watchpoint, or gives an error that makes sense if the watchpoint creation command was malformed/illegal in some way.

Additional info:
I have no idea where the bug might be from, but if I had to try I'd try to determine if it's gdb's fault (in reading the debuginfo), binutils's fault (in generating the debuginfo) or something else. Also, as a result of this, the component I've specified for the bug is somewhat likely to be wrong, I have no idea if gdb is actually the component to blame here and I've based my choice of component on the basis that I observed the bug when using it.

Comment 1 Kevin Buettner 2023-02-03 23:15:40 UTC

I'm able to reproduce this problem using both gdb-12.1-7.fc37 and upstream GDB (14.0.50.20230203-git).  Thus it appears that there's no upstream fix yet, or at least nothing that's been committed/pushed.

With regard to the DWARF, here's what I see:

 <1><468f1>: Abbrev Number: 112 (DW_TAG_subprogram)
    <468f2>   DW_AT_external    : 1
    <468f2>   DW_AT_name        : (indirect string, offset: 0x4781): jq_util_input_next_input
    <468f6>   DW_AT_decl_file   : 10
    <468f6>   DW_AT_decl_line   : 411
    <468f8>   DW_AT_decl_column : 4
    <468f9>   DW_AT_prototyped  : 1
    <468f9>   DW_AT_type        : <0x3f2>
    <468fd>   DW_AT_sibling     : <0x4692e>
...
 <2><46921>: Abbrev Number: 102 (DW_TAG_variable)
    <46922>   DW_AT_name        : (indirect string, offset: 0x8cb): value
    <46926>   DW_AT_decl_file   : 10
    <46926>   DW_AT_decl_line   : 414
    <46928>   DW_AT_decl_column : 6
    <46929>   DW_AT_type        : <0x3f2>

Note that there's no DW_AT_location, so I looked for an abstract origin entry:

 <2><2dfa0>: Abbrev Number: 90 (DW_TAG_variable)
    <2dfa1>   DW_AT_abstract_origin: <0x46921>
    <2dfa5>   DW_AT_location    : 0x27cf1 (location list)
    <2dfa9>   DW_AT_GNU_locviews: 0x27ce1

(Note that the DW_AT_abstract_origin attribute's value is 0x46921 which is the DIE for the local variable "value".)

Looking at the location list, I see:

    00027cf1 v000000000000000 v000000000000000 views at 00027ce1 for:
             000000000002f8fe 000000000002f92e (DW_OP_reg13 (r13); DW_OP_GNU_uninit; DW_OP_piece: 8; DW_OP_reg12 (r12); DW_OP_GNU_uninit; DW_OP_piece: 8)

I think that this is probably correct. It appears to me that the problem is that GDB doesn't understand the use of DW_OP_GNU_uninit in conjunction with the use of DW_OP_piece.

I think that this bug is correctly assigned to "gdb".  I'll see what I can do about it...

Comment 2 Mark Wielaard 2023-02-20 11:40:55 UTC

I recently fixed an issue in elfutils libdw with DW_OP_GNU_uninit. But we mostly just ignore DW_OP_GNU_uninit. It seems not very well specified and not that useful. Here it seems to say "Look the value is in r13 (and the next piece is in r12), O, but the value in r13/r12 is not initialized, so you can regard it as not existing anyway..."

It would be good if gdb didn't reject the DWARF as invalid, but I think we should lobby GCC to not emit it. Unless someone sees how this is really helpful (having a non-existing or empty location list seems more useful than having one with DW_OP_GNU_uninit in it).

Comment 3 Kevin Buettner 2023-06-03 18:38:41 UTC

I've posted a patch and test case for this problem to the (upstream) gdb-patches list:

https://sourceware.org/pipermail/gdb-patches/2023-June/200054.html