From mboxrd@z Thu Jan 1 00:00:00 1970 From: Elena Zannoni To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com, ezannoni@cygnus.com Subject: Re: Buffering problems with "gdb < foo" Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <14531.61750.823726.628635@kwikemart.cygnus.com> References: <200003050850.DAA10185@indy.delorie.com> X-SW-Source: 2000-q1/msg00550.html Eli Zaretskii writes: > > A comment in event-top.c (inside the change_line_handler function) > says this: > > /* NOTE: this operates on input_fd, not instream. If we are reading > commands from a file, instream will point to the file. However in > async mode, we always read commands from a file with editing > off. This means that the 'set editing on/off' will have effect > only on the interactive session. */ > > However, running "gdb < foo" seems to contradict this: I put a > breakpoint in gdb_readline2, and it is never hit. Am I missing > something? > Yeah, I tried to think hard about all the possible cases, but obvioulsy I missed this one. > The problem with this is that if the file `foo' includes a command > which needs a confirmation, the call to fgetc in query will eatup lots > of characters which will never again be seen by the event loop. In my > case, fgetc read all the file (it was small), so GDB hit EOF and > exited. I can prevent this from happening by putting "set editing off" > in the input file. Invoking GDB with --noasync also solves the > problem. > Yep. > Does this work on Unix? If so, it would make this a DJGPP-specific > problem. I haven't tried, but probably it won't. Can you send me your command file? > > If this is not DJGPP-specific, then I think _initialize_event_loop > should turn editing off if input_fd is not a tty. I think so, can you submit a patch to do this? Thanks. Elena >From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs To: "H . J . Lu" Cc: gdb-patches@sourceware.cygnus.com, GDB Subject: Re: A patch for gnu-regex Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C585BB.3F7B1AC7@apple.com> References: <20000307134103.A20533@valinux.com> X-SW-Source: 2000-q1/msg00569.html Content-length: 456 "H . J . Lu" wrote: > > I believe gnu-regex is maintained in glibc 2. I'd like to use the one > in glibc 2 instead of the one in gdb. I don't know if there is any more elegant way to handle the linux.mh vs linuxlibc1.mh distinction (although we should try, instead of making still more file semi-clones), but you could simplify the source files by making a gdb_regex.h similar to the other gdb_*.h substitute files, and put the #if sequence in it. Stan >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Discussion Cc: GDB Patches Subject: [MAINT] x86 maintainers ..... Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38BCA2B9.3BDE66AD@cygnus.com> X-SW-Source: 2000-q1/msg00459.html Content-length: 318 Hello, I'd like to put forward the following: x86 target Mark Kettenis kettenis@gnu.org GNU/Linux/x86 native & host Jim Blandy jimb@cygnus.com Mark Kettenis kettenis@gnu.org Solaris/x86 native & host Nick Duffek nsd@cygnus.com Peter Schauer Peter.Schauer@regent.e-technik.tu-muenchen.de Andrew >From jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: command error handling Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5mr9e093zj.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00424.html Content-length: 1257 The CLI for the memory region attributes feature I'm working on is based on displays. Each memory region created is assigned a number, and can be enabled, disabled, and deleted. While stealing the display CLI code, I noticed that when you enable or disable a non-extant display, a message will be output with printf_- unfiltered(), but when you do the same thing with delete, GDB calls error(). The same thing occurs when you attempt to enable/disable/ delete displays with a non-numeric argument. I'll argue that delete should behave like enable and disable, that a message be output and execution should continue. The problem with error(), IMHO, is that it's very heavy handed. While it allows us to avoid the fun of propagating errors up from the lowest levels of GDB, it also makes it impossible for user defined functions to detect the failure of a command (that, plus the fact that there are no command return values, but that's easily remedied by comparision). Without such a mechanism, the usefulness of scripting is greatly diminished. I would expect it to much be the same for all extension languages that may be bound into GDB. Is this a (long-term) direction we should be investigating? --jtc -- J.T. Conklin RedBack Networks >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: akale@veritas.com Cc: toddpw@windriver.com, kingdon@redhat.com, akale@veritas.com, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Regression caused by elfread.c patch Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002151025.e1FAP2D00808@delius.kettenis.local> References: <200002150800.AAA07477@alabama.wrs.com> <00021514224700.31608@fermat.vxindia.veritas.com> X-SW-Source: 2000-q1/msg00293.html Content-length: 2551 From: "Amit S. Kale" Organization: Veritas Software (India) Date: Tue, 15 Feb 2000 13:56:11 +0530 Cc: akale@veritas.com, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Content-Type: text/plain Hi, On Tue, 15 Feb 2000, Jim Kingdon wrote: > > That was because Jim didn't checkin my patch correctly. > > He has fixed it now. > > No, this is a different problem. Apolgies to Jim, because the problem was not his fault as said by me. > I don't see how your patch could work at all - sym->section->index is > a very different number than a SECT_OFF_* code. The SECT_OFF_* code > (which gets fed to ANOFFSET) isn't computed until later in the > function (via the call to record_minimal_symbol_and_info). The patch I sent is working in some configurations. I have been using it for debugging linux kernel. This patch was needed to load module object files using 'add-symbol-file' after loading kernel object file using 'symbol-file'. So kernel modules are using different offsets for .text and .data huh. I guess gdb first prepares text, data, bss segments and following code bfd/section.c:bfd_make_section_anyway(): newsect->index = abfd->section_count++; indicates that section->index contains SECT_OFF_* codes when segments are loaded. This may not have been designed this way, but it seems to be that way. I don't think the above is true. Using sym->section->index is not right for segments that are not text or data segments. Using sym->section->index should be all right for data segments. Using sym->sections->index is not right for any section. It just happens to be right for kernel modules where the numbering of .text, .data and .bss is identical to the SECT_OFF_* codes. In my libc .text is section 16 (at least for a computer scientist :)) and .data is 20. So sym->sections->index cannot be used without fixing a lot of other code. I suggest following patch. I have verified that the vfprintf problem reported by Mark does not appear with this patch. I haven't tested it with test suite. Apart from the fact that your patch is reversed, this isn't the right solution. Now GDB will be unable to find symbols in the data section. You probaby can get away with using SECT_OFF_DATA instead of sym->section->index, but that might not work for .bss in kernel modules, and I don't think we should accept that patch without at least some comments about this braindamage. Mark >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Discussion , GDB Patches Subject: [MAINT] More additions Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38D80C7E.BF2217E8@cygnus.com> X-SW-Source: 2000-q1/msg00764.html Content-length: 537 Hello, Michael and Jim are going to share breakpoint code between themselves: breakpoint.c Michael Snyder msnyder@cygnus.com Jim Blandy jimb@cygnus.com Jonathan Larmour's just managed to exceed his quota of good patch submissions :-). He's happy to join the write aver approval list: Jonathan Larmour jlarmour@redhat.co.uk David has stepped forward as the SPARC/Solaris and target maintainer: sparc target David Taylor taylor@cygnus.com Solaris/SPARC native & host David Taylor taylor@cygnus.com enjoy, Andrew >From hjl@valinux.com Sat Apr 01 00:00:00 2000 From: "H . J . Lu" To: Kevin Buettner Cc: GDB Subject: Re: Does today's gdb compile on Linux? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000118140028.A2029@valinux.com> References: <20000118100532.A7871@valinux.com> <1000118184306.ZM1103@ocotillo.lan> <20000118104731.B7970@valinux.com> <1000118193156.ZM1576@ocotillo.lan> X-SW-Source: 2000-q1/msg00045.html Content-length: 952 I mananged to compile it under the glibc 2.1.3 in CVS. But thread debugging doesn't work: # gdb linuxthreads/ex1 (gdb) r Starting program: /work/build/gnu/bin/glibc-2.1/linuxthreads/ex1 [New Thread 1024 (runnable)] Nothing happened. When I typed "Ctrl-C", I got thread_db: map_id2thr failed: invalid thread handle (gdb) bt #0 0x2aafa2e9 in __sigsuspend (set=0x7ffff75c) at ../sysdeps/unix/sysv/linux/sigsuspend.c:48 #1 0x2aacfcc7 in __pthread_wait_for_restart_signal (self=0x2aad7840) at pthread.c:744 #2 0x2aacf4d9 in __pthread_create_2_1 (thread=0x7ffff8c8, attr=0x0, start_routine=0x8048520 , arg=0x80486ad) at restart.h:26 #3 0x8048583 in main () at Examples/ex1.c:26 #4 0x2aaf4371 in __libc_start_main (main=0x8048568
, argc=1, argv=0x7ffff934, init=0x804838c <_init>, fini=0x8048674 <_fini>, rtld_fini=0x2aab5c04 <_dl_fini>, stack_end=0x7ffff92c) at ../sysdeps/generic/libc-start.c:92 (gdb)