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

[Daniel Jacobowitz <dmj+@andrew.cmu.edu>]

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