Re: [PATCHv4 2/2] gdb: Initial baremetal riscv support

[Simon Marchi <simark@simark.ca>]

On 2018-03-05 05:45, Andrew Burgess wrote:
> Simon,
> 
> Thanks for the continued feedback.  The only changes in this revision
> are in the new test.  I believe I've addressed all of the points you
> made:
> 
>   - Test file renamed.
>   - General cleanup, redundant code removed.
>   - Use of clean_restart where appropriate.
>   - Use of 'fail' after 'runto_main'.
>   - Use of get_valueof where appropriate.
>   - Use of gdb_assert where appropriate.
>   - The integer only set is also included now.
> 
> One interesting change that cropped up with this change is that I now
> run the tests _after_ having the inferior program call a function that
> uses the FPU.  The reason is that on one machine I was seeing test
> failures in some cases.
> 
> The reason I believe is due to lazy enabling of the FPU on x86-64
> targets.  I think that what happens is this:
> 
>   1. Program starts, FPU is disabled.  Contents of $fctrl and $fstat
>      registers is random garbage.
>   2. User makes an inferior call from GDB, GDB stores complete
>      register state.
>   3. Inferior function uses the FPU, the kernel enables the FPU and
>      places some sane defaults into the $fctrl and $fstat registers.
>   4. Inferior function completes and control returns to GDB, GDB
>      restores the contents of the $fctrl and $fstat registers
>      (original random garbage) however, the FPU is now enabled.
>   5. Use calls another inferior function from GDB, the FPU is now
>      already enabled but has random garbage in its control registers,
>      this sometimes results in a SIGFPU exception.
> 
> I then noticed that the gdb.base/structs.exp test also fails for me on
> the "problem" machine.
> 
> What I don't know is why this issue is limited to one particular
> machine, I'm guessing its something special about the OS/GCC/libraries
> but I've not tracked it down yet.
> 
> Still, I thought it was interesting enough to mention, but I don't
> think it needs to block this patch from moving forward.

Ok, I don't know more about the FPU than you do, and your explanation 
seems reasonable.

The patch LGTM.

Thanks!

Simon