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

[Hui Zhu <teawater at gmail dot com>]

Current code for arm-record cannot pass testsuite?

Thanks,
Hui

On Sun, Jun 24, 2012 at 4:41 PM, Yao Qi <yao@codesourcery.com> wrote:
> 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 (éå)