Re: [PATCH] arm-syscall record support [phase-3]

[Yao Qi <yao at codesourcery dot com>]

On Tuesday, June 19, 2012 09:30:28 PM oza Pawandeep wrote:
> I do remember the result, But I understood that the results are
> failing mainly because of thumb2 and syscall missing support.
> Chandra K was working on improving the test suite (but no hear from him).

I run tests in gdb.reverse under arm mode (-marm), so the instructions in 
executable are 32-bit arm mode insns.  Although the thumb-2 insns are used in 
system libc in my board, we can see some fails appeared in main executable.  I 
doubt there may be some bugs your phase-2 patch.

> The confusing part for me is;
> 
> 1) How Do I run gdb.reverse ?
> (I think I need to run them in gdb server mode, where host is x86 and
> target is ARM, how did you run it ?)
> [and along with that all the test code has to be cross compiled)
> 

See http://sourceware.org/gdb/wiki/TestingGDB
"Testing gdbserver in a remote cross-target configuration".  It is about 
testing gdb with gdbserver running powerpc64, but you can modify it for your 
setting.  AFAICS, you have to modify following settings in that board file,

  set_board_info compiler  "/opt/at4.0/bin/powerpc64-linux-gcc"
  set_board_info c++compiler  "/opt/at4.0/bin/powerpc64-linux-g++"

These two should be the location of your arm-cross compiler on your host (your 
pc).

  # Path to the gdbserver executable on target board.
  set_board_info gdb_server_prog /home/user/gdbserver-devel/gdbserver

  set_board_info username user
  set_board_info hostname remote.example.com
  set_board_info sockethost "remote.example.com:"

> 2)
> Yao > "reverse/record doesn't consider software-single-step, because
> i368 and amd64 doesn't need it.  I pointed out the similar problem
> when reviewing your phase-2 patch, but it was not addressed."
> 
> Oza : I do not get this much; Can you please elaborate on it ?
> 

My point is about the cause of that gdb internal error.  I don't know much 
about how that gdb internal error is caused, but it is related to software-
single-step.  The whole record infrastructure doesn't consider much on 
software-single-step, iirc, we have to fix it.

> 3) If syscall and thumb2 test cases are falling in unexpected failure
> then until we support them it might always be unexpected failures;
> what do we do about that ?

In theory, if fails are caused by the limitation or missing features in GDB, 
we should kfail them.  However, we'd better analyze each of them to see if 
they are caused by missing syscall and thumb-2 support or not.  Fix existing 
bugs first, and we can revisit this when existing bugs are fixed and want to 
run gdb.reverse on arm port in default, IMO.

> 
> 4) I shall definitely work on "Process record does not support
> instruction at  0xXXXXX" which must be resolved and I would like to
> see those working.

Thanks.

> 
> 5) What I would do is; instead of going for syscall patch; I shall fix
> as many things as possible. then I shall integrate syscall record
> support.

Yes, my point is that we should fix fails found in existing testsuite as much 
as we can, and write some new tests to cover arm-specific part if needed.  
When you finish 'record syscall' work, run testsuite, see how much the test 
result is improved.  The test result improvement is a good evidence to 
convince maintainers to accept your change.

-- 
Yao (éå)