Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Philipp Rudo <prudo@linux.vnet.ibm.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: gdb-patches@sourceware.org, omair.javaid@linaro.org,
	yao.qi@linaro.org,        peter.griffin@linaro.org,
	arnez@linux.vnet.ibm.com
Subject: Re: [RFC v4 8/9] Link frame_info to thread_info
Date: Mon, 19 Jun 2017 15:46:00 -0000	[thread overview]
Message-ID: <20170619174507.0daa763a@ThinkPad> (raw)
In-Reply-To: <86tw3cnn28.fsf@gmail.com>

Hi Yao

On Mon, 19 Jun 2017 14:07:11 +0100
Yao Qi <qiyaoltc@gmail.com> wrote:

> Philipp Rudo <prudo@linux.vnet.ibm.com> writes:
> 
> > Linux kernel stacks on S390 are spread over several memory locations.
> > These locations differ for every kernel task/thread.  Thus we need to know
> > to which task/thread a frame belongs to check whether a stack pointer is
> > valid and when to stop unwinding.  To do so add a pointer to corresponding
> > thread_info to frame_info.
> >
> > This connection already exists implicitly by the fact that switch_to_thread
> > reinitializes the frame cache.  
> 
> The whole frame cache is created for current thread, from sentinel
> frame.  When the current thread is changed, the frame cache will be
> re-created.  If we see different frame_info objects are about different
> threads, it must be a bug somewhere.  I think frame_info.thread always
> points to the current thread, no?

That's also the way I understand it how it should work.

My problem with it is that such implicit connections via global variables are
extremely error prone and hard to debug.  For example look at
linux-tdep.c:linux_corefile_thread, here the code looks like this

static void                                                                     
linux_corefile_thread (struct thread_info *info,
                       struct linux_corefile_thread_data *args)
{
  [...]

  old_chain = save_inferior_ptid ();
  inferior_ptid = info->ptid;
  target_fetch_registers (regcache, -1);

  [...]
}

At this point the inferior_ptid is changed without re-creating the frame
cache.  Thus the assumption that a existing frame_info always belongs to
current_thread is wrong at this point.  What makes it worse is that right after
a target hook is called.  So suddenly you have a connection between a
target_obs and a gdbarch you'd never expect which can lead to a bug...

For me the easiest way to prevent such long range bugs is not to use global
variables but explicit connections between the different subsystems.

That's why I made this patch.

Philipp

P.S. I know that the example is bad and you shouldn't use the frame cache to
fetch registers but I hope you get the point I was trying to make.


  reply	other threads:[~2017-06-19 15:46 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-12 17:08 [RFC v4 0/9] Support for Linux kernel debugging Philipp Rudo
2017-06-12 17:08 ` [RFC v4 2/9] Add libiberty/concat styled concat_path function Philipp Rudo
2017-06-12 17:08 ` [RFC v4 4/9] Add kernel module support for linux-kernel target Philipp Rudo
2017-06-12 17:08 ` [RFC v4 3/9] Add basic Linux kernel support Philipp Rudo
2017-06-15 15:23   ` Yao Qi
2017-06-16 10:10     ` Philipp Rudo
2017-06-16 11:43       ` Pedro Alves
2017-06-19  7:56         ` Philipp Rudo
2017-06-19  9:52       ` Yao Qi
2017-06-19 13:35         ` Omair Javaid
2017-06-19 15:44         ` Philipp Rudo
2017-06-12 17:08 ` [RFC v4 1/9] Convert substitute_path_component to C++ Philipp Rudo
2017-06-12 17:08 ` [RFC v4 7/9] Add privileged registers for s390x Philipp Rudo
2017-06-19 13:34   ` Yao Qi
2017-06-19 15:46     ` Philipp Rudo
2017-06-12 17:08 ` [RFC v4 8/9] Link frame_info to thread_info Philipp Rudo
2017-06-19 13:07   ` Yao Qi
2017-06-19 15:46     ` Philipp Rudo [this message]
2017-06-12 17:08 ` [RFC v4 5/9] Add commands for linux-kernel target Philipp Rudo
2017-06-12 17:09 ` [RFC v4 6/9] Separate common s390-tdep.* from s390-linux-tdep.* Philipp Rudo
2017-06-12 17:39 ` [RFC v4 9/9] Add S390 support for linux-kernel target Philipp Rudo
2017-06-19 13:20   ` Yao Qi
2017-06-19 15:45     ` Philipp Rudo
2017-06-12 21:17 ` Philipp Rudo

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=20170619174507.0daa763a@ThinkPad \
    --to=prudo@linux.vnet.ibm.com \
    --cc=arnez@linux.vnet.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=omair.javaid@linaro.org \
    --cc=peter.griffin@linaro.org \
    --cc=qiyaoltc@gmail.com \
    --cc=yao.qi@linaro.org \
    /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