From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Eli Zaretskii Cc: hjl@lucon.org, gdb@sourceware.cygnus.com Subject: Re: Hardware watchpoints Date: Sun, 24 Oct 1999 12:22:00 -0000 Message-id: References: <19991019235249.917DC1B494@ocean.lucon.org> <199910201401.KAA28719@mescaline.gnu.org> <199910221200.IAA24556@mescaline.gnu.org> <199910231048.GAA31392@mescaline.gnu.org> X-SW-Source: 1999-q4/msg00151.html > Thanks for the explanations. (I hope I wasn't explaining stuff you already knew!! :) ) > An abridged script of a GDB session follows. As you see, I watched > two different members of a struct variable `foo_var': `foo_var.iv' and > `foo_var.jv'. GDB produced two value chains, each one including the > struct member and the struct itself--all of them marked as lazy. Ahh! I think I know the problem. > Perhaps we could use v->type.code in the decision whether to watch any > values but the first one on the value chain? I don't think that's quite right. > One question that I still can't figure out is why does GDB at all > _need_ to have the parent struct on the value chain? Where is that > information used? GDB doesn't *need* it, per se. It's just that, as evaluate_expression runs, as it walks the expression, each operator, variable, constant, etc. produces a struct value, holding the value of that subexpression. I think, before watchpoints were implemented, the only reason GDB ever chained them together was so it could free them before reading the next user command. Whoever implemented watchpoints noticed that the value chain also happened to form a list of the objects touched by an expression, and thus a list of things which might need to be watched. The problem is that nobody ever uses the value returned by the call to evaluate_expression in insert_breakpoints, so it remains lazy. Try this, in addition to my previous change: *** breakpoint.c 1999/10/21 19:16:52 1.254 --- breakpoint.c 1999/10/24 19:21:53 *************** *** 851,856 **** --- 851,858 ---- /* Evaluate the expression and cut the chain of values produced off from the value chain. */ v = evaluate_expression (b->exp); + if (VALUE_LAZY (v)) + value_fetch_lazy (v); value_release_to_mark (mark); b->val_chain = v; >From ac131313@cygnus.com Sun Oct 24 17:53:00 1999 From: Andrew Cagney To: richard.earnshaw@arm.com Cc: Grant Edwards , "J.T. Conklin" , Grant.Edwards@comtrol.com, gdb@sourceware.cygnus.com Subject: Re: wrong htons() used? Date: Sun, 24 Oct 1999 17:53:00 -0000 Message-id: <3813A9AC.D896D4BD@cygnus.com> References: <199910221526.QAA16254@cam-mail1.cambridge.arm.com> X-SW-Source: 1999-q4/msg00152.html Content-length: 655 Richard Earnshaw wrote: > > > I thing the best option is to rename rdi-share/endian.h so that it > > doesn't shadow /usr/include/endian.h. rdi-share/endian.h doesn't > > appeart to be some strictly local stuff and not intented as a > > replacement for /usr/include/endian.h. > > And maybe while they are fixing it they can track down and shoot the glibc > person who put another non-standard header in a standard place... Unfortunatly you would have to go back a long way. Endian.h has a (C) date of 1992. More seriously, why is picking up the wrong endian.h? Has this always happened or has something else recently changed? Andrew >From ac131313@cygnus.com Sun Oct 24 18:21:00 1999 From: Andrew Cagney To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: async event loop and ^C Date: Sun, 24 Oct 1999 18:21:00 -0000 Message-id: <3813B055.5C62C3C7@cygnus.com> References: <5mzoxbl03y.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00153.html Content-length: 538 "J.T. Conklin" wrote: > > What is the recommended way to handle this? I see that remote.c > installs a new SIGINT handler while waiting for execution. I can do > the same, but it doesn't seem right. > FYI, That's very old code being given a tempoary makeover. It isn't right (it is better than it was though - at least remote.c now provides terminal_ours/terminal_inferior). The implementation of the double cntrl-c mechanism is eventually being moved out of remote.c. Remote.c would only see the call to target_stop(). Andrew >From grante@visi.com Sun Oct 24 18:31:00 1999 From: Grant Edwards To: Andrew Cagney Cc: richard.earnshaw@arm.com, "J.T. Conklin" , Grant.Edwards@comtrol.com, gdb@sourceware.cygnus.com Subject: Re: wrong htons() used? Date: Sun, 24 Oct 1999 18:31:00 -0000 Message-id: <19991024203029.A3662@visi.com> References: <199910221526.QAA16254@cam-mail1.cambridge.arm.com> <3813A9AC.D896D4BD@cygnus.com> X-SW-Source: 1999-q4/msg00154.html Content-length: 1001 On Mon, Oct 25, 1999 at 10:51:56AM +1000, Andrew Cagney wrote: > > > > I thing the best option is to rename rdi-share/endian.h so that it > > > doesn't shadow /usr/include/endian.h. rdi-share/endian.h doesn't > > > appeart to be some strictly local stuff and not intented as a > > > replacement for /usr/include/endian.h. > > > > And maybe while they are fixing it they can track down and shoot the glibc > > person who put another non-standard header in a standard place... > > Unfortunatly you would have to go back a long way. Endian.h has a (C) > date of 1992. > > More seriously, why is picking up the wrong endian.h? > Has this always happened or has something else recently changed? It seems that it's been this way for quite a while. The e-mail I got from the JTAG interface box vendor said that in the past, people just changed the #define for the port number so that it worked. Apparently there was only one spot where it mattered. -- Grant Edwards grante@visi.com