This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]