public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 7/8] Initialise target descrption after skipping extra traps for --wrapper
Date: Fri, 24 Jul 2015 11:52:00 -0000	[thread overview]
Message-ID: <55B22711.4080307@redhat.com> (raw)
In-Reply-To: <86bnf1hksj.fsf@gmail.com>

On 07/24/2015 12:11 PM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> Instead of this whole code block, I think we should be able to skip
>> the bits in the function that require accessing registers.  E.g.,
>> this:
>>
>>  /* Cancel actions that rely on GDB not changing the PC (e.g., the
>>      user used the "jump" command, or "set $pc = foo").  */
>>   if (lwp->stop_pc != get_pc (lwp))
>>     {
>>       /* Collecting 'while-stepping' actions doesn't make sense
>> 	 anymore.  */
>>       release_while_stepping_state_list (thread);
>>     }
>>
>> Could be guarded by:
>>
>>   if (thread->while_stepping != NULL)
>>
>> And this:
>>
>>   if (the_low_target.get_pc != NULL)
>>     {
>>       struct regcache *regcache = get_thread_regcache (current_thread, 1);
>>
>>       lwp->stop_pc = (*the_low_target.get_pc) (regcache);
>>
>>       if (debug_threads)
>> 	{
>> 	  debug_printf ("  %s from pc 0x%lx\n", step ? "step" : "continue",
>> 			(long) lwp->stop_pc);
>> 	}
>>     }
>>
>> could be guarded by:
>>
>>   if (proc->tdesc == NULL)
>>
>> Did you try that?
> 
> To make sure I understand you correctly, is the change below what you suggested?

Yes.

> If yes, I thought about this approach before, but I didn't try that
> because I was worried that we should check every piece of code in
> linux_resume_one_lwp_throw and its callees that don't access registers
> when target description isn't initialised yet.  Especially for
> the_low_target.prepare_to_resume, the implementation of this hook should
> be aware of that target description may not be available.  Nowadays,
> prepare_to_resume is only used to update HW debug registers, and
> should be OK because GDBserver shouldn't update HW debug registers
> before the inferior stops at the first instruction of the program.
> However, in nat/x86-linux.c:lwp_debug_registers_changed, I saw such
> comments
> 
>   struct arch_lwp_info *info = lwp_arch_private_info (lwp);
> 
>   /* NULL means either that this is the main thread still going
>      through the shell, or that no watchpoint has been set yet.
>      The debug registers are unchanged in either case.  */
> 
> I was wondering all the implementations of prepare_to_resume of
> different targets should be aware that "thread still going through the
> shell"?  

Yes, I think they should.  It's what the GDB side used to do already
when that code was x86 gdb only (and hence that shell comment, which
gdbserver doesn't use yet), and then other archs followed suit.
"Going through the shell" is the exact same as going through
the exec wrapper -- we're not interested in debugging the shell,
and it may well have a different bitness/architecture of the target
program we want to debug.

In practice that hook's implementation should want to avoid work if some
flag is not set, to avoid unnecessary ptrace syscalls and thus ends up
not doing anything when going through the shell/exec-wrapper.

> I'll test this patch on targets other than x86 (such as arm and
> aarch64) and see if it causes fails.

Thanks,
Pedro Alves

  reply	other threads:[~2015-07-24 11:52 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-20 11:35 [PATCH 0/8] Fix various issues in --wrapper in GDBserver Yao Qi
2015-07-20 11:35 ` [PATCH 1/8] Disallow using --attach and --wrapper together Yao Qi
2015-07-23 22:29   ` Pedro Alves
2015-07-24  8:44     ` Yao Qi
2015-07-24  8:51       ` Pedro Alves
2015-07-20 11:35 ` [PATCH 4/8] Test --wrapper when restarting process Yao Qi
2015-07-23 22:59   ` Pedro Alves
2015-07-20 11:35 ` [PATCH 2/8] Test --wrapper in extended-remote Yao Qi
2015-07-23 22:35   ` Pedro Alves
2015-07-20 11:36 ` [PATCH 5/8] Refactor start_inferior Yao Qi
2015-07-23 23:27   ` Pedro Alves
2015-07-20 11:36 ` [PATCH 8/8] Remove proc->priv->new_inferior Yao Qi
2015-07-23 23:27   ` Pedro Alves
2015-07-20 11:36 ` [PATCH 6/8] Set proc->priv->new_inferior out of linux_add_process Yao Qi
2015-07-23 23:26   ` Pedro Alves
2015-07-20 11:36 ` [PATCH 7/8] Initialise target descrption after skipping extra traps for --wrapper Yao Qi
2015-07-23 23:26   ` Pedro Alves
2015-07-24 11:12     ` Yao Qi
2015-07-24 11:52       ` Pedro Alves [this message]
2015-07-24 13:08         ` Yao Qi
2015-07-24 13:44           ` Pedro Alves
2015-07-20 11:36 ` [PATCH 3/8] Set general_thread after restart Yao Qi
2015-07-23 22:58   ` Pedro Alves
2015-07-24  9:33     ` Yao Qi
2015-07-24  9:53       ` Pedro Alves
2015-07-24 11:31         ` Yao Qi
2015-07-24 13:49 ` [PATCH 0/8] Fix various issues in --wrapper in GDBserver Yao Qi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55B22711.4080307@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).