This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA/tracepoint] Make GDB can work with some old GDB server


Ping.

On Fri, Jun 24, 2011 at 16:46, Hui Zhu <teawater@gmail.com> wrote:
> Hi,
>
> I got some bug report about ppa in https://lkml.org/lkml/2011/6/4/65
> It is:
> kgdb_breakpoint () at kernel/kgdb.c:1721
> 1721 ? ? ? ? ? ?wmb(); /* Sync point after breakpoint */
> Sending packet: $qSymbol::#5b...Ack
> Packet received:
> Packet qSymbol (symbol-lookup) is NOT supported
> Sending packet: $qTStatus#49...Ack
> Packet received: E22
> trace API error 0x2.
> (gdb) bt
> No stack.
> (gdb)
>
> This is because this kgdb(I think trunk have fixed this bug) don't
> support qtstatus and reply -0x22.
> So gdb throw a error. ?Then all connect process stop.
>
> This is a bug of kgdb, but I think make gdb just output a warning is
> not affect anything else. ?So I make this patch.
>
> Please help me review it.
>
> Thanks,
> Hui
>
>
> 2011-06-24 ?Hui Zhu ?<teawater@gmail.com>
>
> ? ? ? ?* remote.c (remote_start_remote): Add TRY_CATCH for
> ? ? ? ?remote_get_trace_status.
> ? ? ? ?* tracepoint.c (disconnect_tracing): Ditto.
> ---
> ?remote.c ? ? | ? 13 ++++++++++++-
> ?tracepoint.c | ? 14 +++++++++++++-
> ?2 files changed, 25 insertions(+), 2 deletions(-)
>
> --- a/remote.c
> +++ b/remote.c
> @@ -3146,6 +3146,8 @@ remote_start_remote (int from_tty, struc
> ? struct remote_state *rs = get_remote_state ();
> ? struct packet_config *noack_config;
> ? char *wait_status = NULL;
> + ?int ret = 0;
> + ?volatile struct gdb_exception ex;
>
> ? immediate_quit++; ? ? ? ? ? ?/* Allow user to interrupt it. ?*/
>
> @@ -3389,7 +3391,16 @@ remote_start_remote (int from_tty, struc
>
> ? /* Possibly the target has been engaged in a trace run started
> ? ? ?previously; find out where things are at. ?*/
> - ?if (remote_get_trace_status (current_trace_status ()) != -1)
> + ?TRY_CATCH (ex, RETURN_MASK_ERROR)
> + ? ?{
> + ? ? ?ret = remote_get_trace_status (current_trace_status ());
> + ? ?}
> + ?if (ex.reason < 0)
> + ? ?{
> + ? ? ?warning(_("%s"), ex.message);
> + ? ? ?ret = -1;
> + ? ?}
> + ?if (ret != -1)
> ? ? {
> ? ? ? struct uploaded_tp *uploaded_tps = NULL;
> ? ? ? struct uploaded_tsv *uploaded_tsvs = NULL;
> --- a/tracepoint.c
> +++ b/tracepoint.c
> @@ -1939,11 +1939,23 @@ trace_status_mi (int on_stop)
> ?void
> ?disconnect_tracing (int from_tty)
> ?{
> + ?int ret = 0;
> + ?volatile struct gdb_exception ex;
> +
> ? /* It can happen that the target that was tracing went away on its
> ? ? ?own, and we didn't notice. ?Get a status update, and if the
> ? ? ?current target doesn't even do tracing, then assume it's not
> ? ? ?running anymore. ?*/
> - ?if (target_get_trace_status (current_trace_status ()) < 0)
> + ?TRY_CATCH (ex, RETURN_MASK_ERROR)
> + ? ?{
> + ? ? ?ret = target_get_trace_status (current_trace_status ());
> + ? ?}
> + ?if (ex.reason < 0)
> + ? ?{
> + ? ? ?warning(_("%s"), ex.message);
> + ? ? ?ret = -1;
> + ? ?}
> + ?if (ret < 0)
> ? ? current_trace_status ()->running = 0;
>
> ? /* If running interactively, give the user the option to cancel and
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]