* Amusing problem in current libthread_db @ 2003-06-03 22:09 Daniel Jacobowitz 2003-06-03 22:30 ` Roland McGrath 0 siblings, 1 reply; 10+ messages in thread From: Daniel Jacobowitz @ 2003-06-03 22:09 UTC (permalink / raw) To: gdb, libc-alpha In recent versions of libthread_db, there's this interesting code: td_err_e td_thr_getgregs (const td_thrhandle_t *th, prgregset_t gregs) { struct _pthread_descr_struct pds; LOG ("td_thr_getgregs"); if (th->th_unique == NULL) { /* No data yet. */ memset (gregs, '\0', sizeof (prgregset_t)); return TD_OK; } So, if we don't have a th_unique, claim to have no registers. So for the first thread, until the thread manager is initialized [for LinuxThreads at least - is it initialized earlier in NPTL?], we claim that all registers are zero. GDB loads the registers during this interval. So it thinks the PC is zero. Anyone know the reason for this change, which appears to have come in with: date: 2002/07/16 03:35:49; author: drepper; state: Exp; lines: +7 -0 Some more changes to handle TLS-enabled libpthread. It doesn't seem to cause any problems, which baffles me just a little bit. I'm still trying to figure that part out. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Amusing problem in current libthread_db 2003-06-03 22:09 Amusing problem in current libthread_db Daniel Jacobowitz @ 2003-06-03 22:30 ` Roland McGrath 2003-08-18 19:33 ` Daniel Jacobowitz 0 siblings, 1 reply; 10+ messages in thread From: Roland McGrath @ 2003-06-03 22:30 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb, libc-alpha The reason that code is needed for linuxthreads is that the thread descriptor might be uninitialized. The main thread and the manager thread are always reported by td_ta_thr_iter. However, early on their descriptors are all zeros and so td_thr_get_info et al need to be able to cope with that. It might make more sense not to report any threads at all before they are initialized enough to report useful information. But I think that was deemed a more risky change (vs possible presumptions of old gdbs, etc) than faking the all-zeros responses in the early stages. The reason this wasn't an issue before and got changed was that the array of thread descriptors used to be in initialized data, where the first two elements were initialized nonzero to set up the the main and manager threads. Now the whole array is in uninitialized so it can go in bss and not take up space on disk; thus the main and manager threads' elements start out zero too. td_thr_get_info does a somewhat more convincing job of faking info when dealing with an uninitialized descriptor in the inferior, i.e. always just use the main thread in that case. td_thr_getgregs et al could be made to do that. Thanks, Roland ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Amusing problem in current libthread_db 2003-06-03 22:30 ` Roland McGrath @ 2003-08-18 19:33 ` Daniel Jacobowitz 2003-08-19 6:45 ` Machine interface jacques 2003-08-25 8:17 ` Amusing problem in current libthread_db Ulrich Drepper 0 siblings, 2 replies; 10+ messages in thread From: Daniel Jacobowitz @ 2003-08-18 19:33 UTC (permalink / raw) To: Roland McGrath; +Cc: gdb, libc-alpha On Tue, Jun 03, 2003 at 03:30:47PM -0700, Roland McGrath wrote: > The reason that code is needed for linuxthreads is that the thread > descriptor might be uninitialized. The main thread and the manager thread > are always reported by td_ta_thr_iter. However, early on their descriptors > are all zeros and so td_thr_get_info et al need to be able to cope with > that. It might make more sense not to report any threads at all before > they are initialized enough to report useful information. But I think that > was deemed a more risky change (vs possible presumptions of old gdbs, etc) > than faking the all-zeros responses in the early stages. > > The reason this wasn't an issue before and got changed was that the array > of thread descriptors used to be in initialized data, where the first two > elements were initialized nonzero to set up the the main and manager threads. > Now the whole array is in uninitialized so it can go in bss and not take up > space on disk; thus the main and manager threads' elements start out zero too. > > td_thr_get_info does a somewhat more convincing job of faking info when > dealing with an uninitialized descriptor in the inferior, i.e. always just > use the main thread in that case. td_thr_getgregs et al could be made to > do that. Will the manager thread be reported as created only after its thread descriptor is initialized? I'm guessing "yes". In that case, using the main thread is sufficient. Here's a patch to fix the problem, since it turned out to be more than theoretical on ARM targets. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer 2003-08-18 Daniel Jacobowitz <drow@mvista.com> * td_thr_getfpregs.c (td_thr_getfpregs): Use the main thread if the descriptor is uninitialized. * td_thr_getgregs.c (td_thr_getgregs): Likewise. diff -urp -x '*~' glibc-2.3.2/linuxthreads_db.orig/td_thr_getfpregs.c glibc-2.3.2/linuxthreads_db/td_thr_getfpregs.c --- glibc-2.3.2/linuxthreads_db.orig/td_thr_getfpregs.c 2002-07-15 23:25:16.000000000 -0400 +++ glibc-2.3.2/linuxthreads_db/td_thr_getfpregs.c 2003-08-18 14:44:11.000000000 -0400 @@ -1,5 +1,5 @@ /* Get a thread's floating-point register set. - Copyright (C) 1999, 2001 Free Software Foundation, Inc. + Copyright (C) 1999, 2001, 2003 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Ulrich Drepper <drepper@cygnus.com>, 1999. @@ -30,7 +30,10 @@ td_thr_getfpregs (const td_thrhandle_t * if (th->th_unique == NULL) { - memset (regset, '\0', sizeof (*regset)); + /* No data yet. Use the main thread. */ + pid_t pid = ps_getpid (th->th_ta_p->ph); + if (ps_lgetfpregs (th->th_ta_p->ph, pid, regset) != PS_OK) + return TD_ERR; return TD_OK; } diff -urp -x '*~' glibc-2.3.2/linuxthreads_db.orig/td_thr_getgregs.c glibc-2.3.2/linuxthreads_db/td_thr_getgregs.c --- glibc-2.3.2/linuxthreads_db.orig/td_thr_getgregs.c 2002-07-15 23:24:27.000000000 -0400 +++ glibc-2.3.2/linuxthreads_db/td_thr_getgregs.c 2003-08-18 14:43:08.000000000 -0400 @@ -1,5 +1,5 @@ /* Get a thread's general register set. - Copyright (C) 1999, 2000, 2001 Free Software Foundation, Inc. + Copyright (C) 1999, 2000, 2001, 2003 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Ulrich Drepper <drepper@cygnus.com>, 1999. @@ -30,8 +30,10 @@ td_thr_getgregs (const td_thrhandle_t *t if (th->th_unique == NULL) { - /* No data yet. */ - memset (gregs, '\0', sizeof (prgregset_t)); + /* No data yet. Use the main thread. */ + pid_t pid = ps_getpid (th->th_ta_p->ph); + if (ps_lgetregs (th->th_ta_p->ph, pid, gregs) != PS_OK) + return TD_ERR; return TD_OK; } ^ permalink raw reply [flat|nested] 10+ messages in thread
* Machine interface 2003-08-18 19:33 ` Daniel Jacobowitz @ 2003-08-19 6:45 ` jacques 2003-08-19 13:30 ` Andrew Cagney 2003-08-25 8:17 ` Amusing problem in current libthread_db Ulrich Drepper 1 sibling, 1 reply; 10+ messages in thread From: jacques @ 2003-08-19 6:45 UTC (permalink / raw) Cc: gdb Hello, I've been doing some MI interface testing, and am in need of some grammar clarifications. After running until a breakpoint, I do the following: (gdb) -data-evaluate-expression b ^done,value="{<_Vector_base<int,std::allocator<int> >> = {<_Vector_alloc_base<int,std::allocator<int>,true>> = {_M_start = 0x804aa50, _M_finish = 0x804aa58, _M_end_of_storage = 0x804aa58}, <No data fields>}, <No data fields>}" Which is of the format: output => result-record => "^" result-class ( "," result ) result-class => "done" result => variable "=" value value => tuple tuple => "{" result "}" ... Now all is well and fine, however the meat of the output, being the variable and value nonterminal symbols are unparseable! Indeed, they are composed of: variable => string value => const => c-string (since I can't fanthom not running into a const value after a while) In this case, <_Vector_base<....>> is unparseable, and I wouldn't be able to know how to handle all cases. Furthermore, I don't see the distinction between c-string and string. I see how the production would depend on the programming language being being debugged, but it seems quite important to me. --Jacques ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Machine interface 2003-08-19 6:45 ` Machine interface jacques @ 2003-08-19 13:30 ` Andrew Cagney 2003-08-19 14:00 ` Alain Magloire 0 siblings, 1 reply; 10+ messages in thread From: Andrew Cagney @ 2003-08-19 13:30 UTC (permalink / raw) To: jacques; +Cc: gdb Have a look at the -var-* commands. The testsuite is currently the best source of examples. Andrew ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Machine interface 2003-08-19 13:30 ` Andrew Cagney @ 2003-08-19 14:00 ` Alain Magloire 0 siblings, 0 replies; 10+ messages in thread From: Alain Magloire @ 2003-08-19 14:00 UTC (permalink / raw) To: Andrew Cagney; +Cc: jacques, gdb > > Have a look at the -var-* commands. The testsuite is currently the best > source of examples. > In other words try: (gdb) -var-create - * b ... -var-evaluate-expression var1 Using the varobj, as shown to be more reliable. and we use -data-evaluate-expression only for hovering or quick evaluation. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Amusing problem in current libthread_db 2003-08-18 19:33 ` Daniel Jacobowitz 2003-08-19 6:45 ` Machine interface jacques @ 2003-08-25 8:17 ` Ulrich Drepper 1 sibling, 0 replies; 10+ messages in thread From: Ulrich Drepper @ 2003-08-25 8:17 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Roland McGrath, gdb, libc-alpha -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Jacobowitz wrote: > Here's a patch to fix the problem, since it turned out to be more than > theoretical on ARM targets. I supposed this isn't worse than what we had before. I've applied it. - -- - --------------. ,-. 444 Castro Street Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA Red Hat `--' drepper at redhat.com `--------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/ScYM2ijCOnn/RHQRAn0mAJ9BkL1WvRWWZ7vl0iyuorUhnZWvOQCgynbO T2b5NBhnYj/p1a+9Gbz/FK0= =VEMF -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Machine interface @ 2005-03-18 16:01 Greg Law 2005-03-18 16:05 ` Bob Rossi 0 siblings, 1 reply; 10+ messages in thread From: Greg Law @ 2005-03-18 16:01 UTC (permalink / raw) To: gdb Hi, I'm trying to find some info on GDB/MI. I've read the info pages. They seem to be half finished, and specifically don't talk about one actually interfaces with gdb/mi. ie. it doesn't seem to be via stdin of the gdb processes (typing -break-point at it causes "unknown command" errors. Do I need to open a socket to it or some such? Or do I just have the MI syntax wrong? TIA, Greg ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Machine interface 2005-03-18 16:01 Machine interface Greg Law @ 2005-03-18 16:05 ` Bob Rossi 2005-03-18 16:11 ` Daniel Jacobowitz 0 siblings, 1 reply; 10+ messages in thread From: Bob Rossi @ 2005-03-18 16:05 UTC (permalink / raw) To: Greg Law; +Cc: gdb On Fri, Mar 18, 2005 at 04:00:57PM +0000, Greg Law wrote: > Hi, > > I'm trying to find some info on GDB/MI. I've read the info pages. They > seem to be half finished, and specifically don't talk about one actually > interfaces with gdb/mi. ie. it doesn't seem to be via stdin of the gdb > processes (typing -break-point at it causes "unknown command" errors. > Do I need to open a socket to it or some such? Or do I just have the MI > syntax wrong? If you start GDB on the command line, you can use GDB the same way you use the CLI, of course with different syntax. The documentation for setting breakpoints in MI mode is here, http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC250 in particular, try, '-break-insert main' Bob Rossi ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Machine interface 2005-03-18 16:05 ` Bob Rossi @ 2005-03-18 16:11 ` Daniel Jacobowitz 0 siblings, 0 replies; 10+ messages in thread From: Daniel Jacobowitz @ 2005-03-18 16:11 UTC (permalink / raw) To: Greg Law, gdb On Fri, Mar 18, 2005 at 11:05:36AM -0500, Bob Rossi wrote: > On Fri, Mar 18, 2005 at 04:00:57PM +0000, Greg Law wrote: > > Hi, > > > > I'm trying to find some info on GDB/MI. I've read the info pages. They > > seem to be half finished, and specifically don't talk about one actually > > interfaces with gdb/mi. ie. it doesn't seem to be via stdin of the gdb > > processes (typing -break-point at it causes "unknown command" errors. > > Do I need to open a socket to it or some such? Or do I just have the MI > > syntax wrong? > > If you start GDB on the command line, you can use GDB the same way you > use the CLI, of course with different syntax. > > The documentation for setting breakpoints in MI mode is here, > http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC250 > > in particular, try, '-break-insert main' More specifically, Greg, I think you're missing the "-i=mi" option. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2005-03-18 16:11 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-06-03 22:09 Amusing problem in current libthread_db Daniel Jacobowitz 2003-06-03 22:30 ` Roland McGrath 2003-08-18 19:33 ` Daniel Jacobowitz 2003-08-19 6:45 ` Machine interface jacques 2003-08-19 13:30 ` Andrew Cagney 2003-08-19 14:00 ` Alain Magloire 2003-08-25 8:17 ` Amusing problem in current libthread_db Ulrich Drepper 2005-03-18 16:01 Machine interface Greg Law 2005-03-18 16:05 ` Bob Rossi 2005-03-18 16:11 ` Daniel Jacobowitz
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).