Re: Buffering problems with "gdb < foo"

Re: Buffering problems with "gdb < foo"

[Elena Zannoni]

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 <shebs@apple.com>
To: "H . J . Lu" <hjl@valinux.com>
Cc: gdb-patches@sourceware.cygnus.com, GDB <gdb@sourceware.cygnus.com>
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 <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
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 <kettenis@wins.uva.nl>
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" <akale@veritas.com>
   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 <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
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" <hjl@valinux.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: GDB <gdb@sourceware.cygnus.com>
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> <hjl@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 <process>, arg=0x80486ad) at restart.h:26
#3  0x8048583 in main () at Examples/ex1.c:26
#4  0x2aaf4371 in __libc_start_main (main=0x8048568 <main>, 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) 

Re: Buffering problems with "gdb < foo"

[Eli Zaretskii]

>  > 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? 

Attached.  Even though the particular problem that triggered this was
elsewhere (see my other message in this thread), I still think that
when stdin comes from a file, editing should be disabled by default.

2000-03-08  Eli Zaretskii  <eliz@is.elta.co.il>

	* event-top.c (_initialize_event_loop): If instream is not
	connecetd to a terminal device, turn editing off.

--- gdb/event-top.c~0	Sat Mar  4 18:28:20 2000
+++ gdb/event-top.c	Wed Mar  8 00:56:42 2000
@@ -1133,9 +1133,25 @@ _initialize_event_loop (void)
 {
   if (event_loop_p)
     {
-      /* When a character is detected on instream by select or poll,
-         readline will be invoked via this callback function. */
-      call_readline = rl_callback_read_char_wrapper;
+      /* If the input stream is connected to a terminal, turn on
+         editing.  */
+      if (ISATTY (instream))
+	{
+	  /* Tell gdb that we will be using the readline library. This
+	     could be overwritten by a command in .gdbinit like 'set
+	     editing on' or 'off'. */
+	  async_command_editing_p = 1;
+	  
+	  /* When a character is detected on instream by select or
+	     poll, readline will be invoked via this callback
+	     function. */
+	  call_readline = rl_callback_read_char_wrapper;
+	}
+      else
+	{
+	  async_command_editing_p = 0;
+	  call_readline = gdb_readline2;
+	}
 
       /* When readline has read an end-of-line character, it passes
          the complete line to gdb for processing. command_line_handler
@@ -1160,10 +1176,5 @@ _initialize_event_loop (void)
          only when it actually exists (I.e. after we say 'run' or
          after we connect to a remote target. */
       add_file_handler (input_fd, stdin_event_handler, 0);
-
-      /* Tell gdb that we will be using the readline library. This
-         could be overwritten by a command in .gdbinit like 'set
-         editing on' or 'off'. */
-      async_command_editing_p = 1;
     }
 }
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Alexis Denis <adenis@EE.UManitoba.CA>, gdb@sourceware.cygnus.com
Subject: Re: gdb for java debugging on linuxppc
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000221224836.ZM8885@ocotillo.lan>
References: <38B1AC30.D93D824E@ee.umanitoba.ca> <adenis@EE.UManitoba.CA>
X-SW-Source: 2000-q1/msg00364.html
Content-length: 665

On Feb 21,  4:20pm, Alexis Denis wrote:

> I'm running
>     - linuxppc Q3 with 2.2.14pre9 kernel
>     - gcc snapshot 20000214
>     - libgcj snapshot 20000218
>     - gdb snapshot 000220
> 
> I compiled a simple HelloWorld program in java and it runs fine but when
> I try to run it in the debugger I get:
> Starting program: /home/adenis/java/HelloWorld
> Don't know how to run.  Try "help target".
> 
> Any idea why? Thanks,

The gdb snapshots don't have support for linux/ppc yet.

I'm working on it and should have most of the changes into the sourceware
CVS repository either today or tomorrow.

Kevin

-- 
Kevin Buettner
kev@primenet.com, kevinb@redhat.com
From cshihpin@dso.org.sg Sat Apr 01 00:00:00 2000
From: Chan Shih-Ping Richard <cshihpin@dso.org.sg>
To: gdb@sourceware.cygnus.com
Subject: CVS: Cannot overload resolve std::string.size() in valops.c (fwd)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.LNX.4.10.10003011407170.11100-100000@vermeer.dso.org.sg>
X-SW-Source: 2000-q1/msg00460.html
Content-length: 520

Hi all,

There seems to be an off-by-one error in valops.c that prevents
overload resolution of 
	string s.size();
	string s.length();

Didn't Dan Berlin point this out sometime ago (?)- wonder have
I missed a fix in the CVS. When comparing "goodness-of-fit"
nparms = 0 and nargs = 1. In function find_overload_match 
either
	nargs should be 0
or 
	rank_function should use nargs-1.

Comments?







-- 

Chan Shih-Ping (Richard) <cshihpin@dso.org.sg>
DSO National Laboratories
20 Science Park Drive
Singapore 118230