PATCH: Make gdbserver use async I/O on Linux

PATCH: Make gdbserver use async I/O on Linux

[Daniel Jacobowitz]

The only problem I can think of that this might cause is if F_SETOWN is less
portable than FASYNC.  Apparently you need to do that explicitly on a Linux
target before SIGIO will be sent.

This lets C-c on the host be properly handled, stopping the target.

-- 
Daniel Jacobowitz                           Debian GNU/Linux Developer
Monta Vista Software                              Debian Security Team
From ezannoni@cygnus.com Wed Jun 06 14:10:00 2001
From: Elena Zannoni <ezannoni@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: Properly detect that GDB was compiled without MI support
Date: Wed, 06 Jun 2001 14:10:00 -0000
Message-id: <15134.39998.848755.666987@kwikemart.cygnus.com>
References: <20010605210124.AABD95E9CB@zwingli.cygnus.com>
X-SW-Source: 2001-06/msg00097.html
Content-length: 1679

Jim, I must be seeing double, but I think this output is already
handled in the -re directly below the one you changed.
(Ok I am jet-lagged, so excuse me if I am wrong).

	-re ".*unrecognized option.*for a complete list of options." {
	    untested "Skip mi tests (not compiled with mi support)."
	    remote_close host;
	    return -1;
	}
	-re ".*Interpreter `mi' unrecognized." {
	    untested "Skip mi tests (not compiled with mi support)."
	    remote_close host;
	    return -1;
	}

Elena


Jim Blandy writes:
 > 
 > gdb/testsuite/gdb.mi/ChangeLog-mi:
 > 
 > 2001-06-05  Jim Blandy  <jimb@redhat.com>
 > 
 > 	* lib/mi-support.exp: Recognize new error message, indicating that GDB
 > 	was compiled without MI support.
 > 
 > Index: gdb/testsuite/lib/mi-support.exp
 > ===================================================================
 > RCS file: /cvs/cvsfiles/devo/gdb/testsuite/lib/mi-support.exp,v
 > retrieving revision 1.24
 > diff -c -r1.24 mi-support.exp
 > *** gdb/testsuite/lib/mi-support.exp	2001/01/15 12:28:02	1.24
 > --- gdb/testsuite/lib/mi-support.exp	2001/06/05 20:57:06
 > ***************
 > *** 130,136 ****
 >   	    remote_close host;
 >   	    return -1;
 >   	}
 > ! 	-re ".*unrecognized option.*for a complete list of options." {
 >   	    untested "Skip mi tests (not compiled with mi support)."
 >   	    remote_close host;
 >   	    return -1;
 > --- 130,136 ----
 >   	    remote_close host;
 >   	    return -1;
 >   	}
 > ! 	-re ".*(unrecognized option.*for a complete list of options.)|(Interpreter `mi' unrecognized)" {
 >   	    untested "Skip mi tests (not compiled with mi support)."
 >   	    remote_close host;
 >   	    return -1;
 > 

Re: PATCH: Make gdbserver use async I/O on Linux

[Eli Zaretskii]

On Wed, 6 Jun 2001, Daniel Jacobowitz wrote:

> The only problem I can think of that this might cause is if F_SETOWN is less
> portable than FASYNC.

Exactly.  And that is why I'd suggest to make this change conditioned
on F_SETOWN being defined.

Please note that the original code took care to use the F* macros
only if they were defined:

>  #if defined(F_SETFL) && defined (FASYNC)
>    save_fcntl_flags = fcntl (remote_desc, F_GETFL, 0);
>    fcntl (remote_desc, F_SETFL, save_fcntl_flags | FASYNC);
> +  fcntl (remote_desc, F_SETOWN, getpid());
>    disable_async_io ();
>  #endif /* FASYNC */

This uses F_SETFL and FASYNC only if they are defined.  I suggest to
do the same with F_SETOWN.

Re: PATCH: Make gdbserver use async I/O on Linux

[Daniel Jacobowitz]

On Thu, Jun 07, 2001 at 09:36:23AM +0300, Eli Zaretskii wrote:
> 
> On Wed, 6 Jun 2001, Daniel Jacobowitz wrote:
> 
> > The only problem I can think of that this might cause is if F_SETOWN is less
> > portable than FASYNC.
> 
> Exactly.  And that is why I'd suggest to make this change conditioned
> on F_SETOWN being defined.

Easy enough.  How about this, then?

-- 
Daniel Jacobowitz                           Debian GNU/Linux Developer
Monta Vista Software                              Debian Security Team
From dan@www.cgsoftware.com Thu Jun 07 11:06:00 2001
From: Daniel Berlin <dan@www.cgsoftware.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: Jim Blandy <jimb@cygnus.com>, <gdb-patches@sources.redhat.com>
Subject: Re: [RFA] linespec.c change to stop "malformed template specification"error
Date: Thu, 07 Jun 2001 11:06:00 -0000
Message-id: <Pine.LNX.4.33.0106071404080.17276-100000@www.cgsoftware.com>
References: <15135.47501.950878.977558@kwikemart.cygnus.com>
X-SW-Source: 2001-06/msg00139.html
Content-length: 2872

On Thu, 7 Jun 2001, Elena Zannoni wrote:

> Jim Blandy writes:
>  >
>  > Elena Zannoni <ezannoni@cygnus.com> writes:
>  > >  > Operators like '<' can appear in template arguments.  For example, you
>  > >  > could define a template like this:
>  > >  >
>  > >  >         template <int i> struct list { int a[i], b[i]; };
>  > >  >
>  > >  > and then use it like this:
>  > >  >
>  > >  >         struct list <20> l;
>  > >  >
>  > >  > and you get the same thing as if you'd written:
>  > >  >
>  > >  >         struct { int a[20], b[20]; } l;
>  > >  >
>  > >  > At least I think so, anyway.  I don't really know C++.  But the point
>  > >  > is, those template arguments can be any arbitrary constant expression.
>  > >  > So I could have a template invocation like this:
>  > >  >
>  > >  >         struct list < (x < y) ? 10 : 20 > l;
>  > >  >
>  > >  > So how does our poor little decode_line_1 handle that?  Basically, we
>  > >  > need to replace decode_line_1 with a real parser.
>  > >
>  > > I am not sure that decode_line_1 will ever be invoked in such a case.
>  > > Looking at when it's called, it seems to be only when you specify
>  > > a location, not an expression, and that occurs for 'break blah' and
>  > > 'list blah' only.
>  >
>  > Templates can expand to functions, too:
>  >
>
> Ok, I was looking at your example in a myopic way.
>
>  > template <int i>
>  > int add_const (int j)
>  > {
>  >   return i + j;
>  > }
>  >
>  > then, add_const <4> (3) returns 7.
>  >
>  > But add_const <4> and add_const <5> are different functions.  The
>  > compiler emits separate code for each of them.  So you need to be able
>  > to set a breakpoint on add_const <4>.  And the template argument to
>  > add_const can be any constant expression.
>  >
>  > So finding breakpoint names requires parsing (almost) arbitrary expressions.
>  >
>
> Yes, you are correct. That function (find_toplevel_char) would get it wrong
> if we had something like this, even with Dan's patch:
>
> break foo_class<x>y ? 1 : 2, 4>::foo
>

This isn't relevant, since it won't work now anyway.

We never evaluate the expressions involved in decode_line_1. We just want
to get names.

Try "break (1 < 0):10 ? 5"

It won't breakpoint line 10 or 5, you'll get an error.
;)

This is because we don't ever use the expression evaluator on the
expressions involved.  Line specifications aren't part of the expression
syntax. If they were, we'd just be able to use the language parsers and be
done with it.

It would also mean "print <filename>:<function name>" would work.


> It would think that the greater-than was the end of the template, and
> that the ',' was outside of the template specification.  But, if that
> is a legal expression (I am not sure), how likely would it be?
> Definitely better with Dan's patch than w/o, at least we can catch the
> simpler cases.
>
> Elena
>
~

Re: PATCH: Make gdbserver use async I/O on Linux

[Eli Zaretskii]

> Date: Thu, 7 Jun 2001 10:43:46 -0700
> From: Daniel Jacobowitz <dmj+@andrew.cmu.edu>
> 
> Easy enough.  How about this, then?
> 
> -- 
> Daniel Jacobowitz                           Debian GNU/Linux Developer
> Monta Vista Software                              Debian Security Team
> 
> --ibTvN161/egqYuK8
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: attachment; filename="async2.diff"
> 
> Index: gdb/gdbserver/low-linux.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbserver/low-linux.c,v
> retrieving revision 1.9
> diff -u -r1.9 low-linux.c
> --- low-linux.c	2001/03/28 09:15:22	1.9
> +++ low-linux.c	2001/06/07 17:37:52
> @@ -105,7 +105,9 @@
>    int pid;
>    union wait w;
>  
> +  enable_async_io ();
>    pid = wait (&w);
> +  disable_async_io ();
>    if (pid != inferior_pid)
>      perror_with_name ("wait");
>  
> Index: gdb/gdbserver/remote-utils.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbserver/remote-utils.c,v
> retrieving revision 1.4
> diff -u -r1.4 remote-utils.c
> --- remote-utils.c	2001/03/06 08:21:44	1.4
> +++ remote-utils.c	2001/06/07 17:37:52
> @@ -156,6 +156,9 @@
>  #if defined(F_SETFL) && defined (FASYNC)
>    save_fcntl_flags = fcntl (remote_desc, F_GETFL, 0);
>    fcntl (remote_desc, F_SETFL, save_fcntl_flags | FASYNC);
> +#if defined(F_SETOWN)
> +  fcntl (remote_desc, F_SETOWN, getpid());
> +#endif
>    disable_async_io ();
>  #endif /* FASYNC */
>    fprintf (stderr, "Remote debugging using %s\n", name);
> 
> --ibTvN161/egqYuK8--
> 

Looks good to me.  Thanks!

Re: PATCH: Make gdbserver use async I/O on Linux

[Daniel Jacobowitz]

On Thu, Jun 07, 2001 at 09:35:44PM +0300, Eli Zaretskii wrote:
> 
> Looks good to me.  Thanks!
> 

Which begs the question - is someone actually maintaining gdbserver, or
is it just under the blanket write maintainers?

-- 
Daniel Jacobowitz                           Debian GNU/Linux Developer
Monta Vista Software                              Debian Security Team

Re: PATCH: Make gdbserver use async I/O on Linux

[Eli Zaretskii]

> Date: Thu, 7 Jun 2001 12:04:47 -0700
> From: Daniel Jacobowitz <dmj+@andrew.cmu.edu>
> 
> Which begs the question - is someone actually maintaining gdbserver, or
> is it just under the blanket write maintainers?

Looks like the latter; MAINTAINERS doesn't tell.  Andrew?

Re: PATCH: Make gdbserver use async I/O on Linux

[J.T. Conklin]

>>>>> "Daniel" == Daniel Jacobowitz <dmj+@andrew.cmu.edu> writes:
Daniel> The only problem I can think of that this might cause is if
Daniel> F_SETOWN is less portable than FASYNC.  Apparently you need to
Daniel> do that explicitly on a Linux target before SIGIO will be
Daniel> sent.

The same is true on other targets as well.

I found that Greg McGary submitted a patch quite a long time ago to do
async i/o on Linux and additional targets that was never applied.  I'm
going to rectify that problem and will commit it shortly.

        --jtc

-- 
J.T. Conklin
RedBack Networks