Re: GDB internals: thread infos

Re: GDB internals: thread infos

[Mark Kettenis]

   From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
   Date: Tue, 29 Aug 2000 15:36:35 -0700

   Hi,

   I'm trying to understand how gdb retrieve thread information, thread frame
   and thread pc.

   I started in the info_threads_command  function.

Good point to start :-).

   So there in order to retrieve thread $pc it call the
   functionswitch_to_thread which I presume do only a frame switch.

   So here is this function:

   static void
   switch_to_thread (pid)
	int pid;
   {
     if (pid == inferior_pid)
       return;

     inferior_pid = pid;
     flush_cached_frames ();
     registers_changed ();
     stop_pc = read_pc ();
     select_frame (get_current_frame (), 0);
   }

   I assume that inferior_pid should contain the thread id of the current
   selected thread.

Correct.

   Then I have a few questions:

   What does the registers_changed() should do and where is it
   defined?

Trouble using grep :-).

It tells GDB that any registers it has cached are invalid now.  You
can find the stuff in regcache.c.

   Which pc does the read_pc command should return? The one of the inferior_pid
   thread ?

The one for inferior_pid.

   Then in the get_current_frame function, it ends up calling:
	   current_frame = create_new_frame (read_fp (), read_pc ());

   What frame pointer should read_fp() return? I presume this is the one of the
   thread we are switching too. right?

Indeed.

   idem for read_pc(). But at what point is there an interaction with the
   target to get effectively those values.

If the registers aren't cached by GDB (and they aren't since we just
called registers_changed()) these functions will fetch the registers.
There is a chain of function calls, which ultimately ends with a call
for the target's fetch_inferior_registers().

Mark
From sbjohnson@ozemail.com.au Tue Aug 29 18:01:00 2000
From: Steven Johnson <sbjohnson@ozemail.com.au>
To: gdb@sources.redhat.com
Subject: Register Cache.
Date: Tue, 29 Aug 2000 18:01:00 -0000
Message-id: <39AC598A.DFAF67E9@ozemail.com.au>
References: <8AE4B526B977D411841F00A0CC334020052C28@cuz-exchange.sdesigns.net>
X-SW-Source: 2000-08/msg00158.html
Content-length: 1117

GDB caches it's register reads. ie, it will only read a register once, and
will only write a register if it thinks the value has changed.

For Example:

set $myreg=0x12345678     <-- Results in GDB Actually changing the register.
set $myreg=0x12345678     <-- Filtered by GDB and doesnt set register.

Now this seems fine on the surface, but there are many registers that
the act of writing is sometimes more important than the data (like say a
watchdog reset register). You may need to write the same value multiple times.

I Can find no way of forcing GDB to not cache its register accesses (dcache
also has this problem, but it also has a solution) does anyone know of a way to
force GDB to either always update registers and read registers and not cache
them, or of a way to force GDB to set it's status of these registers as unknown
(and hence making it update from the register).

Ive spent all day hunting through the code ("Using the source" as some would
say) but i'm damned if I can find anything. So I am attempting to introduce my
own solution. But obviously I may have missed something. 

Steven Johnson
From shebs@apple.com Tue Aug 29 18:43:00 2000
From: Stan Shebs <shebs@apple.com>
To: gdb@sources.redhat.com
Subject: Switching to the Lesser GPL
Date: Tue, 29 Aug 2000 18:43:00 -0000
Message-id: <39AC66CE.97B04D5F@apple.com>
X-SW-Source: 2000-08/msg00159.html
Content-length: 1047

One of the things we need to do as part of being good GNUtizens
is to replace instances of the Library GPL with the Lesser GPL.
RMS poked me about this recently, and so I went to take a look.
There seem to be four copies of the Library GPL in GDB sources;
one in the main dir, not referred by to any actual files, and three
in subdirs, with files' copyright notices referring to them:
libiberty, mmalloc, and sim/ppc.

mmalloc is straightforward; the only consideration might be
whether we ought to convert it to GPL, much as readline has
been switched from LGPL to GPL (go to gnu.org licensing pages
for the whole story).

libiberty seems like it should stay LGPL; the main trick here
is to coordinate with GCC, since all the "GNU Library..." strings
in source files change to "GNU Lesser...", thus most files will
be touched.

sim/ppc is entirely GPL, except for one little file words.h.
If Andrew is agreeable, I suggest making it GPL too, and dropping
the LGPL from that dir entirely.

If I've overlooked anything, please let me know...

Stan
From blizzard@redhat.com Tue Aug 29 19:52:00 2000
From: Christopher Blizzard <blizzard@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com
Subject: Re: Linux threads support
Date: Tue, 29 Aug 2000 19:52:00 -0000
Message-id: <39AC77FE.3040708@redhat.com>
References: <200008271535.e7RFZZc04890@delius.kettenis.local> <1000827160616.ZM14856@ocotillo.lan>
X-SW-Source: 2000-08/msg00160.html
Content-length: 1891

Kevin Buettner wrote:

> On Aug 27,  5:35pm, Mark Kettenis wrote:
> 
> > Anyway, I'm now at a point where I think it functions better than the
> > current threads support, and I really need to get it more widely
> > tested.  I see two possibilities:
> > 
> > 1. Post a patch and hope that people take the trouble of applying it.
> > 
> > 2. Put the new code directly in the CVS (possible in a seperate
> >    branch).
> > 
> > I think option 1 is doomed to fail.  For option 2 I'd like some
> > opinions (especially from the maintainers of the various Linux ports):
> 
> I agree with you regarding option 1.  For option 2, I think you should
> just check in your changes on the trunk.  It's scary, but I don't
> think it'll get tested otherwise.
> 
> > * Should the stuff be checked in on a seperate branch?
> 
> As noted above, I don't think a separate branch would be advisable. 
> In fact, I think it's be more likely that people would test your
> changes if you posted a patch than if you created a branch with your
> changes.
> 
> > * How important is support for older Linux systems (pre-libthread_db,
> >   i.e. pre glibc-2.1.3) give the fact that GDB has never had any
> >   satisfactory threads support for these systems, and older versions
> >   of the LinuxThreads library contain many critical bugs?
> 
> I don't see any need to offer thread support for older Linux systems. 
> gdb should still be able to debug non-threaded programs on these
> systems though.

I'm not an expert on gdb but I can say from experience is that if you 
don't check it in where people have to fall all over themselves to not 
use it, it won't get tested.

( Of course, in this case, I would probably test it anyway considering 
my history of thread problems with gdb. )

--Chris

-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
Plan to be spontaneous tomorrow.
------------