This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [RFC][PATCH 00/15] Fast tracepoint support for ARMv7
- From: "Wallin, Henrik" <Henrik dot Wallin at windriver dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Thu, 29 Oct 2015 17:54:24 +0000
- Subject: RE: [RFC][PATCH 00/15] Fast tracepoint support for ARMv7
- Authentication-results: sourceware.org; auth=none
- References: <cover dot 1444820235 dot git dot henrik dot wallin at windriver dot com>,<86r3kgzhs2 dot fsf at gmail dot com>
2015-10-27 12:13 GMT+01:00 Yao Qi <qiyaoltc@gmail.com>:
> henrik.wallin@windriver.com writes:
>
> Hi Henrik,
> First of all, thanks for your patches...
Thanks for taking a look at this.
>> This implements fast tracepoint support for ARMv7. It handles both arm
>> and thumb mode.
>> The first 8 patches are bug-fixes and not directly related to the
>> ARM support and should probably be separated out from this patch set,
>> but I keep them in here for now. The following 7 patches contains the
>> ARM support for fast tracepoint.
>
> As Pedro suggested, please give a test case or steps of reproducing
> these problems your first 8 patches fix.
I will work on the first patches some more regarding testcases.
>
>> There are some left-over issues:
>> - The breakpoint based tracepoints does not work. There is another
>> thread [1] providing needed gdbserver changes to achieve that. Those
>> patches together with these should provide full tracepoint support for
>> ARMv7. (Not verified)
>>
>> - Patch "gdbserver: Add help functions to get arm/thumb mode" needs a
>> better solution.
>>
>> - How to correctly identify that the running ARM cpu is supporting
>> ARMv7-a.
>
> Why do you need to identify the type of ARM cpu? avoid emitting ARMv7
> instructions on ARMv6 CPU?
I guess I'm not sure how gdb identifies different ARM architecture.
I want to be sure that this only are run on those ARMs that it works on.
(ARMv7).
>
>>
>> - No updates done to the testsuite.
>>
>> Known limitations
>> - Current implementation will refuse all instruction that do
>> any relative operation with the PC counter, as relocating such an
>> instruction is non-trivial. This can be improved as some of those
>> instructions can be re-written with alternative instruction(s).
>
> Yes, relocating PC relative instructions is complex for fast tracepoint
> support on any targets. However, if you have free cycles in the future,
> I'd like to see these PC relative instructions are supported in your
> fast tracepoint patches.
>
>>
>> - There is no included jit tracepoint expression optimization
>> included. This should be possible to add.
>>
>
> This needs much work too.
>
>> - Can only set a tracepoint at a 4 bytes instructions, as a 2 bytes
>> slot is too small for the needed jump instruction. This feels like a
>> natural limitation for this functionality, but means that for thumb
>> the user will hit this limitation quite often.
>
> Sounds reasonable to me.
>
>>
>> - The inserted 4 byte jump instruction has a limitation on how far it
>> can branch. The length is validated, but if too far it will not be
>> possible to insert the tracepoint. With very large programs this
>> might be an issue, but again feels like a natural limitation.
>
> Agreed.
>
>>
>> Testing
>> - The internal testsystem has not been run, but I will look into
>> that. I've run other tests on it though and I have no known
>> problems.
>
> Please run GDB testsuite, they are very useful.
>
> One issue you didn't mention here is that GDBserver can't move threads
> out of jump pad without hardware single step. See
> linux-low.c:linux_resume_one_lwp_throw:
>
> else if (fast_tp_collecting == 2)
> {
> if (debug_threads)
> debug_printf ("lwp %ld wants to get out of fast tracepoint jump pad"
> " single-stepping\n",
> lwpid_of (thread));
>
> if (can_hardware_single_step ())
> step = 1;
> else
> {
> internal_error (__FILE__, __LINE__,
> "moving out of jump pad single-stepping"
> " not implemented on this target");
> }
>
> /* Postpone any pending signal. It was enqueued above. */
> signal = 0;
> }
So, isn't there a check somewhere to protect setting breakpoints inside the jump pad? Or do I remember wrong.
Or does this limitation comes into play at other times?
>
> I don't know how much GDBserver software single step (not implemented
> yet) can help here.
No idea. I guess this is related to what Antoine works on.
thanks,
/ Henrik
>
> --
> Yao (齐尧)