From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Re: Difference between *_filtered and *_unfiltered Date: Thu, 21 Oct 1999 18:59:00 -0000 Message-id: <380FC4A4.3D6C8CC1@cygnus.com> References: <19991021171307.87FEC1B493@ocean.lucon.org> <380FAA6A.8BEE418C@cygnus.com> <199910220114.DAA11169@delius.kettenis.local> X-SW-Source: 1999-q4/msg00127.html Mark Kettenis wrote: > > Date: Fri, 22 Oct 1999 10:06:02 +1000 > From: Andrew Cagney > > Totally off topic. > > So I removed a few people from CC: [Er, yes. Oops, Thanks :-)] > > The existing i387-tdep.c has: > > > puts_unfiltered (...); > > It should be using ``..._filtered''. Good time to tweek that as well > :-) > > Could you explain what the difference between the _filtered and > _unfiltered variants is, and under what circumstances one uses the one > or the other? I couldn't find this information in the documentation. Good question. Filtered output goes through a builtin pager (that q for quit or return for more prompt seen when printing a backtrace). Unfiltered output goes straight to the screen. As a rule? All normal output from GDB (display registers, backtrace) should be filtered. A user on an 80x24 terminal doesn't want that register info disappearing off the top of the screen. A user with a large xterminal can use ``(gdb) set height 0''. Output from the target and debug/trace messages generated by gdb's internals should not be filtered. Having gdb prompt for a continue every 24 lines as a result of a ``(gdb) set targetdebug 1'' command will drive the user batty, such output can be captured using other mechanisms such as ``script''. Longer term, the problem will go away. The ..._filtered() and ..._unfiltered() are going to be eliminated. GDB will direct each output to the applicable stream (gdb_stdout, gdb_stdlog, ...) and that stream can then be configured to impose its own paging policy. enjoy, Andrew >From eliz@gnu.org Fri Oct 22 05:00:00 1999 From: Eli Zaretskii To: jimb@cygnus.com Cc: hjl@lucon.org, gdb@sourceware.cygnus.com Subject: Re: Hardware watchpoints Date: Fri, 22 Oct 1999 05:00:00 -0000 Message-id: <199910221200.IAA24556@mescaline.gnu.org> References: <19991019235249.917DC1B494@ocean.lucon.org> <199910201401.KAA28719@mescaline.gnu.org> X-SW-Source: 1999-q4/msg00128.html Content-length: 1411 > > > Evaluating the expression foo.x, I think, produces two values: one for > > > 'foo', which is lazy, and a second for the '.x' member of the first > > > value, which is no longer lazy. > > > > The question is: what happens for foo->x. Since foo can changein this > > case, GDB has to watch both foo and foo->x. But it does NOT have to > > watch *foo. > > Evaluating foo->x, I believe the values on the chain would be foo (not > lazy), and foo->x (not lazy). So that would work correctly. > > Even evaluating (*foo).x, I believe you'd get foo (not lazy), *foo > (lazy), and (*foo).x (not lazy). So that would work too. > > > >Could you suggest a quick hack to test whether this works? If so, I > >could try to see if that solvces the problem (and whether it introduces > >new ones ;-). > > Here's an untested patch: Unfortunately, this doesn't work. The effect of this change is that hardware watchpoints aren't inserted at all. I've poked around a little, and it seems that the lazy flag is set on all members of the struct, not only on the struct itself. It could be that the reason is because value_primitive_field says something like this (in more than one place): if (VALUE_LAZY (arg1)) VALUE_LAZY (v) = 1; I admit that I don't have enough insight into how the lazy flag is used in GDB to suggest a solution. But if you have further ideas for testing, I will try them. Thanks. >From Grant.Edwards@comtrol.com Fri Oct 22 06:52:00 1999 From: Grant.Edwards@comtrol.com To: Andrew Cagney Cc: Scott Bambrough , gdb@sourceware.cygnus.com Subject: Re: wrong htons() used? Date: Fri, 22 Oct 1999 06:52:00 -0000 Message-id: <19991022085150.A26689@comtrol.com> References: <19991021151610.A3919@comtrol.com> <380F80F1.394F7493@netwinder.org> <19991021162144.A15266@comtrol.com> <380FB0FC.A5CE946F@cygnus.com> X-SW-Source: 1999-q4/msg00129.html Content-length: 686 On Fri, Oct 22, 1999 at 10:34:04AM +1000, Andrew Cagney wrote: > I think everyone has agreed that that isn't the problem that is occuring > here. I'm pretty sure that is getting confused by one of the include files in the rdi-remote directory, since that directory is searched first for include files before /usr/include. > Returning to your problem. I think treating the ``tuned/untuned'' > hton*() as the prime suspects is correct. Posibbly tripped by some name > space polution problem. Tried a 3 line program on them? Also, the file > sim/common/sim-endian.c (which I know works :-) might be a useful > reference. -- Grant Edwards Grant.Edwards@comtrol.com >From muller@cerbere.u-strasbg.fr Fri Oct 22 07:24:00 1999 From: Pierre Muller To: gdb@sourceware.cygnus.com Subject: Pascal extensions for GDB Date: Fri, 22 Oct 1999 07:24:00 -0000 Message-id: <199910221437.QAA09979@cerbere.u-strasbg.fr> X-SW-Source: 1999-q4/msg00130.html Content-length: 1505 I would like to submit a big patch for GDB adding support for pascal language ! I am one of the codeveloppers of Free Pascal (a non GNU freeware pascal compiler) for the need of our compiler we (Peter Vreman and myself) wrote pascal extensions to GDB. Our current patch applies quite easily to official GDB 4.18 for djgpp cygwin and i386 linux (I never tried another CPU as at the moment only the i386 part of Free Pascal is being developed intensively and as I have no other CPU available anyway, but the patch has almost nothing processor specific !) Brief description of added features : Features include : - pascal expression parser (maybe incomplete) - case unsensitive regexp patches - language automatic for .p .pp .pas and .inc extensions - support for pascal sets - pascal string (FPC specific, with also printout of values of pointers to pascal strings as for C *char) I sent quite a long time ago a preliminary version of this patch to GPC maintainers but got no feedback, if some GPC developpers are in that list I would like to hear from them ! This patch is approx 750k long so I do not send it directly now ! Please give me some advices about what I should do ! PS : FPC supports long double in 10 bytes instead of 12 like in C ! Is that supported with your current FPU patches ?? Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99 >From scottb@netwinder.org Fri Oct 22 07:49:00 1999 From: Scott Bambrough To: Grant.Edwards@comtrol.com Cc: gdb@sourceware.cygnus.com Subject: Re: wrong htons() used? Date: Fri, 22 Oct 1999 07:49:00 -0000 Message-id: <3810789A.EE0C01AC@netwinder.org> References: <19991021151610.A3919@comtrol.com> <380F80F1.394F7493@netwinder.org> <19991021162144.A15266@comtrol.com> <380FB0FC.A5CE946F@cygnus.com> <19991022085150.A26689@comtrol.com> X-SW-Source: 1999-q4/msg00131.html Content-length: 1021 Grant.Edwards@comtrol.com wrote: > I'm pretty sure that is getting confused by one > of the include files in the rdi-remote directory, since that > directory is searched first for include files before > /usr/include. My ARM and i386 systems are GLIBC2 based (RedHat 6.x). On my system htons(x) resolves to: (x) if __OPTIMIZE__ and __BYTE_ORDER = __BIG_ENDIAN __bswap_16(x) if __OPTIMIZE__ and __BYTE_ORDER = __LITTLE_ENDIAN On my system __BYTE_ORDER is set in on ARM: __BYTE_ORDER == __BIG_ENDIAN if __ARMEB__ is defined __BYTE_ORDER == __LITTLE_ENDIAN otherwise on i386: __BYTE_ORDER == __LITTLE_ENDIAN always In the preprocessed output of etherdrv.c with optimization on is htons(x) reduced to (x) or a call to __bswap_16(x)? The answer to this should tell you if __BYTE_ORDER == __BIG_ENDIAN or __LITTLE_ENDIAN. After that you will need to find out why either __BIG_ENDIAN is defined or __bswap_16(x) fails. Of course this assumes you have a GLIBC2 based system. Scott >From grante@visi.com Fri Oct 22 07:55:00 1999 From: Grant Edwards To: Scott Bambrough Cc: Grant.Edwards@comtrol.com, gdb@sourceware.cygnus.com Subject: Re: wrong htons() used? Date: Fri, 22 Oct 1999 07:55:00 -0000 Message-id: <19991022095507.A4048@visi.com> References: <19991021151610.A3919@comtrol.com> <380F80F1.394F7493@netwinder.org> <19991021162144.A15266@comtrol.com> <380FB0FC.A5CE946F@cygnus.com> <19991022085150.A26689@comtrol.com> <3810789A.EE0C01AC@netwinder.org> X-SW-Source: 1999-q4/msg00132.html Content-length: 1323 On Fri, Oct 22, 1999 at 10:45:46AM -0400, Scott Bambrough wrote: > > > I'm pretty sure that is getting confused by one > > of the include files in the rdi-remote directory, since that > > directory is searched first for include files before > > /usr/include. > > My ARM and i386 systems are GLIBC2 based (RedHat 6.x). > > On my system htons(x) resolves to: > > (x) if __OPTIMIZE__ and __BYTE_ORDER = __BIG_ENDIAN > __bswap_16(x) if __OPTIMIZE__ and __BYTE_ORDER = __LITTLE_ENDIAN > > On my system __BYTE_ORDER is set in > > on ARM: > __BYTE_ORDER == __BIG_ENDIAN if __ARMEB__ is defined > __BYTE_ORDER == __LITTLE_ENDIAN otherwise > > on i386: > __BYTE_ORDER == __LITTLE_ENDIAN always > > In the preprocessed output of etherdrv.c with optimization on is > htons(x) reduced to (x) or a call to __bswap_16(x)? htons(x) with optimization on reduces to (x) htons(x) with optimization off reduces to htons(x) > The answer to this should tell you if __BYTE_ORDER == __BIG_ENDIAN > or __LITTLE_ENDIAN. Apparently it is __BIG_ENDIAN. Which is wrong, since it's a 386. > After that you will need to find out why either __BIG_ENDIAN is defined > or __bswap_16(x) fails. Of course this assumes you have a GLIBC2 based > system. I do. (RH6.0) -- Grant Edwards grante@visi.com