This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2] gdb/riscv: Stop prologue scan if instruction fetch/decode fails
On Mon, Nov 5, 2018 at 3:10 PM Andrew Burgess
<andrew.burgess@embecosm.com> wrote:
> If the target has not yet had a program loaded into it, and the $pc
> value is pointing an unreadable memory, then the prologue scan would
> throw an error, this would then cause GDB to abandon its attempt to
> connect to the target. It was in fact impossible to connect to the
> target at all.
In my case, with openocd/spike, the pc value is actually correct and
there is a valid instruction there. The problem rather happens in
riscv_frame_cache which calls get_frame_func, and this returns 0
because there is no program loaded yet. This then causes a scan for
the prologue to start at address zero, which is wrong, and leads to
the null deref error that kills the connection. I have a simpler fix
based on code I found in mips-tdep.c, which just returns from
riscv_frame_cache if start_addr is zero, and also in
riscv_frame_this_id we don't set this_id if the frame_base is zero.
With your fix, riscv_scan_prologue will be run, the frame cache will
be filled with incorrect values, and we will try to compute a frame id
based on bad info. That doesn't look like the right solution to me.
My patch is a slightly cleaned up version of the workarounds I sent to
you last week, which I am testing now.
Jim
PS Did you see my code_elim testcase fix? Simon Marchi suggested that
you should review it.