[PATCH] Fix assertion fi->level

[Mark Williams]

The problem seems to be that jit_frame_prev_register returns a value
with lval == not_lval, so the value returned from
get_frame_register_value ends up with lval == not_lval, rather than
lval == lval_register.

This is hidden by value_of_register_lazy/value_fetch_lazy, because
value_of_register_lazy creates a value like this:

  reg_val = allocate_value_lazy (register_type (gdbarch, regnum));
  VALUE_LVAL (reg_val) = lval_register;
  VALUE_REGNUM (reg_val) = regnum;

and then value_fetch_lazy gets a new_val with lval==not_lval, but then
copies its contents into the reg_val created by value_of_register_lazy
without overwriting the lval field.

This seems wrong... if an unwinder says its returning a value thats
not an lval, it doesn't seem correct for value_fetch_lazy to turn it
into one. On the other hand, it does seem to work as an lval, so the
bug is probably in jit_frame_prev_register? I'm just not familiar
enough with the code to know what the correct fix is...

In any case, the simple fix for my patch is to call
value_of_register_lazy/value_fetch_lazy when there *is* a valid
frame_id, and get_frame_register_value when there isn't. That way it
only changes the behavior when it was going to crash anyway. I'll go
with that unless someone has a better suggestion...

New patch attached.

On Fri, Feb 7, 2020 at 1:08 PM Mark Williams <mark@myosotissp.com> wrote:
>
> Thanks, I'll take a look.
>
> On Fri, Feb 7, 2020 at 1:05 PM Tom Tromey <tom@tromey.com> wrote:
> >
> > >>>>> "Mark" == Mark Williams <mark@myosotissp.com> writes:
> >
> > Mark> Apparently I should ping the thread after 2 weeks with no response...
> >
> > Yeah.
> >
> > Mark> Note that python unwinders are completely unusable in gdb-8.1 and
> > Mark> later without this fix...
> >
> > Thanks.
> >
> > I read the patch, and I think it looks reasonable.  However, since we
> > were considering it for gdb 9 in another thread, I applied it and ran
> > the test suite.  It caused a few regressions, like:
> >
> > gdb.base/jit-reader.exp: with jit-reader: after mangling: caller frame: cannot a
> > ssign to register: PASS => FAIL
> > gdb.mi/mi-reg-undefined.exp: register values, format r, frame 1: PASS => FAIL
> > gdb.mi/mi-reg-undefined.exp: register values, format r, frame 2: PASS => FAIL
> > gdb.mi/mi-reg-undefined.exp: register values, format x, frame 1: PASS => FAIL
> > gdb.mi/mi-reg-undefined.exp: register values, format x, frame 2: PASS => FAIL
> >
> >
> > Here's some stuff from gdb.log:
> >
> > me: print pseudo register
> > print $rbp = -1
> > Left operand of assignment is not an lvalue.
> > (gdb) FAIL: gdb.base/jit-reader.exp: with jit-reader: after mangling: caller frame: cannot assign to register
> >
> >
> > 221-data-list-register-values --thread 1 --frame 1 x  0 1 2 8 9
> > ~"../../binutils-gdb/gdb/value.c:389: internal-error: int value_bits_any_optimiz
> > ed_out(const value*, int, int): Assertion `!value->lazy' failed.\nA problem inte
> > rnal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit th
> > is debugging session? (y or n) "
> > FAIL: gdb.mi/mi-reg-undefined.exp: register values, format x, frame 1 (timeout)
> >
> >
> > I didn't investigate any further but there's still some issue to be
> > worked out.
> >
> > thanks,
> > Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-gdb-Fix-Assertion-fi-level-0-failed.patch
Type: application/octet-stream
Size: 5777 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20200209/8fdfb1e4/attachment.obj>