This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2 v2] Re-check fastpoint after reloading symbols.
- From: Wei-cheng Wang <cole945 at gmail dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>, gdb-patches at sourceware dot org
- Date: Sun, 13 Sep 2015 02:01:44 +0800
- Subject: Re: [PATCH 1/2 v2] Re-check fastpoint after reloading symbols.
- Authentication-results: sourceware.org; auth=none
- References: <1441074040-65069-1-git-send-email-cole945 at gmail dot com> <86si6wyg43 dot fsf at gmail dot com> <CAPmZyH61j2ECFu7vcg6ZAyhJWNGHpUHk60fOfkXG5qb9M-5pFA at mail dot gmail dot com>
Hi Yao,
Thank you for looking into this.
https://sourceware.org/ml/gdb-patches/2015-06/msg00589.html
Ulrich suggested me to check whether the fast tracepoint is valid on GDB side.
However, if it returns false, it will cause an internal error in
remote_download_tracepoint.
And this patch is for that issue.
As you said in previous mail. If it's not right to check the validity
based on the assumption of
where the jumppad is. Maybe it should always return 'yes' for powerpc
in ppc_fast_tracepoint_valid_at
(or simply use default_fast_tracepoint_valid_at)
Any suggestion, Ulrich?
Thanks,
Wei-cheng
On Sun, Sep 13, 2015 at 1:31 AM, Wei-cheng Wang <cole945@gmail.com> wrote:
> Hi Yao,
>
> Thank you for looking into this.
>
> https://sourceware.org/ml/gdb-patches/2015-06/msg00589.html
> Ulrich suggested me to check whether the fast tracepoint is valid on GDB
> side.
> However, if it returns false, it will cause an internal error in
> remote_download_tracepoint.
>
> As you said in previous mail. If it's not right to check the validity based
> on the assumption of
> where the jumppad is. Maybe it should always return 'yes' for powerpc in
> ppc_fast_tracepoint_valid_at
> (or simply use default_fast_tracepoint_valid_at)
>
> Any suggestion, Ulrich?
>
> Thanks,
> Wei-cheng
>
>
> On Wed, Sep 2, 2015 at 11:51 PM, Yao Qi <qiyaoltc@gmail.com> wrote:
>>
>> Wei-cheng Wang <cole945@gmail.com> writes:
>>
>> Hi Wei-cheng,
>>
>> > I just realized that disabled tracepoints will still be downloaded
>> > on the target by 'tstart' command, and they can be re-enabled (by
>> > QTEnable packet) when trace is running, so I cannot simply disable
>> > an invalid tracepoint to prevent invalid tracepoint being downloaded.
>> >
>> > Scenario 1: the trace is not running.
>> >
>> > Because all tracepoints will be downloaded, when 'tstart', it doesn't
>> > matter whether they are disabled or not. I think if any invalid
>> > tracepoint is found, simply throw an error to force user to delete
>> > invalid tracepoint.
>> >
>> > Scenario 2: the trace is already running.
>> >
>> > I think the check should be placed before update_global_location_list,
>> > because it will try to download new tracepoints on target.
>> > (download_tracepoint_locations). update_breakpoint_locations will not
>> > download disabled tracepoints, so we should disable invalid tracepoints
>> > before calling update_global_location_list.
>> > (see: should_be_inserted in download_tracepoint_locations)
>> >
>> > Otherwise, if we don't disable invalid tracepoints, an error is thrown,
>> > and the program will stop at _dl_debug_state. Then the user has to
>> > delete
>> > the tracepoint manually to continue the execution.
>> >
>> > If a pending tracepoint is resovled after trace is running, and the user
>> > tries to enable an invalid tracepoint after , server will report an
>> > error that it is not installed. It won't run into internal error.
>> >
>> > Any suggestion?
>>
>> I didn't follow your previous tracepoint patches, so I don't understand
>> what problem are you trying to fix in this patch. Nowadays, GDB sends
>> fast tracepoint to GDBserver, if GDBserver can't install it (jump pad is
>> too far from tracepoint), GDBserver will return error, and GDB knows
>> about it. Do you want to do the check in GDB side rather than GDBserver
>> side?
>>
>> --
>> Yao (éå)
>
>