Re: [PATCH] [RISC-V]: Handling optimized prologue

[Andrew Burgess <aburgess@redhat.com>]

Lifang Xia <lifang_xia@c-sky.com> writes:

Hello Lifang,

Thanks for working on this.

> From: Lifang Xia <lifang_xia@linux.alibaba.com>
>
> The optimizer might shove anything into the prologue, if
> we build up cache (cache != NULL) from scanning prologue,
> we just skip what we don't recognize and scan further to
> make cache as complete as possible.

My concern here would be, what if the thing you are skipping over
modifies the state in such a way, that when we think we are building the
cache, we're really doing the wrong thing in some way...


>                                      However, if we skip
> prologue, we'll stop immediately on unrecognized
> instruction.
>
> The case is:
>
> ----------------------------
> Disassembly of section .text:
>
> 0000000000010078 <foo>:
>    10078:       00100513                li      a0,1
>    1007c:       008000ef                jal     ra,10084 <bar>
>    10080:       00008067                ret
>
> 0000000000010084 <bar>:
>    10084:       00051263                bnez    a0,10088 <bar+0x4>
>    10088:       ff010113                addi    sp,sp,-16
>    1008c:       00813023                sd      s0,0(sp)
>    10090:       00050413                mv      s0,a0
>    10094:       00113423                sd      ra,8(sp)
>    10098:       014000ef                jal     ra,100ac <aaa>
>    1009c:       00813083                ld      ra,8(sp)
>    100a0:       00013403                ld      s0,0(sp)
>    100a4:       01010113                addi    sp,sp,16
>    100a8:       00008067                ret
>
> 00000000000100ac <aaa>:
>    100ac:       00000013                nop
>>> 100b0:       00008067                ret
> ----------------------
> (gdb) bt
> #0  0x00000000000100b0 in aaa ()
> #1  0x000000000001009c in bar ()
> Backtrace stopped: frame did not save the PC

I assume it's the bnez that's causing the problem for the prologue scan
here?

Not that I really understand what that instruction is about, it appears
to be branching to the next instruction.  I wonder if this objdump
output is for the object file, rather than the executable?  I'm guessing
the bnez has a reloc which points at, maybe, the ret at 0x100a8?

I wonder if a better solution in this case would be to allow the
prologue scan to skip over forward branches within the prologue, maybe
with the limitation that the destination has to be within the function
bounds?

>
> gdb/
> 	* riscv-tdep.c (riscv_scan_prologue): Keep scaning if cache is not NULL.
> ---
>  gdb/riscv-tdep.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c
> index 886996c..e46d441 100644
> --- a/gdb/riscv-tdep.c
> +++ b/gdb/riscv-tdep.c
> @@ -1987,7 +1987,15 @@ riscv_scan_prologue (struct gdbarch *gdbarch,
>        else
>  	{
>  	  end_prologue_addr = cur_pc;
> -	  break;
> +
> +	  /* The optimizer might shove anything into the prologue, if
> +	     we build up cache (cache != NULL) from scanning prologue,
> +	     we just skip what we don't recognize and scan further to
> +	     make cache as complete as possible.  However, if we skip
> +	     prologue, we'll stop immediately on unrecognized
> +	     instruction.  */
> +	  if (cache == NULL)

Use nullptr not NULL please.

Thanks,
Andrew



> +	    break;
>  	}
>      }
>  
> -- 
> 2.7.4