From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: Fabrice_Gautier@sdesigns.com Cc: gdb@sourceware.cygnus.com Subject: Re: GDB internals: thread infos Date: Tue, 29 Aug 2000 15:50:00 -0000 Message-id: <200008292250.e7TMoPS00812@delius.kettenis.local> References: <8AE4B526B977D411841F00A0CC334020052C33@cuz-exchange.sdesigns.net> X-SW-Source: 2000-08/msg00157.html From: Fabrice Gautier 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 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 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 To: Kevin Buettner Cc: Mark Kettenis , 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. ------------