This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 1/2 v2] Re-check fastpoint after reloading symbols.
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Wei-cheng Wang <cole945 at gmail dot com>
- Cc: uweigand at de dot ibm dot com, gdb-patches at sourceware dot org
- Date: Wed, 02 Sep 2015 16:51:08 +0100
- 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>
Wei-cheng Wang <firstname.lastname@example.org> writes:
> 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?