headers
Nick Roberts | 1 Aug 2005 01:33
Picon

Re: PATCH: tests for MI commands

 > > I never intended to leave things broken.  You have asked me to fix the
 > > failures, and I will, but I'm not sure if that means submit further
 > > patches to the mailing list or commit appropriate fixes.  Based on Mark
 > > Kettenis' e-mail,
 > 
 > Submit patches, please.

OK.

 > > I attach a simple fix for mi-var-child.exp.  Does it work in your case?  I
 > 
 > > 2005-07-28  Nick Roberts  <nickrob <at> snap.net.nz>
 > > 
 > > 	* gdb.mi/mi-var-child.exp: Allow struct_declarations.character to be
 > > 	uninitialized.
 > 
 > First of all, it won't work.  You added:
 >   value=\"0 '\\\\\\\\$decimal'\"
 > which still has 0 in it :-)

Oops!

 > Second, I get a value of 0 here, but the test still fails. 
 > func_ptr_struct and func_ptr_ptr aren't initialized either.  Chasing
 > uninitialized members is going to leave the tests script a bit of a
 > mess.
 > 
 > Initializing the whole structure proved to be a bit of a pain - these
 > tests are ridiculously tricky to edit.  But here it is.  Tested on
 > i686-pc-linux-gnu and committed.  I hope this will be more useful if we
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nick Roberts | 1 Aug 2005 01:17
Picon

Re: PATCH: tests for MI commands

 > > I would rather copy my changes to mi-stack.exp and mi-var-child.exp over to
 > > mi2-stack.exp and mi2-var-child.exp.  Creating new files mi-var-cmd.c,
 > > mi-basics.c etc seems more complicated.  Is this an acceptable short term
 > > solution?
 > 
 > It's not complicated at all.  Please see the attached patch, which I've
 > checked in.  It would be even simpler than this if folks had used
 > ${srcfile} to begin with.

Well now some mi-*.exp files e.g mi-var-block.exp use var-cmd.c while
others, namely mi-var-child.exp, use mi-var-child.c.  Clearly, though if
you do the work its simpler (for me!).

 > Tested on i686-pc-linux-gnu, where it resolves 18 FAILs and assorted
 > ERRORs.

Thanks.  I'll test them on my other machine, but I'm sure they will work.  I
guess the idea is that mi2-*.exp tests shouldn't change although I'm still not
convinced that they are useful - perhaps we can discuss that later.

In future, I'll run the whole testsuite before submitting patches, to save you
and others hassle.

Nick
Permalink | Reply | 1 comment |
headers
Nick Roberts | 1 Aug 2005 01:25
Picon

Re: MI testsuite to use PTY for inferior

 > >  I think you should at least test for ptys first, so that the old tests are
 > > run if/when they are not available.
 > 
 > Won't do any good - expect relies on PTYs.  If the system the tests are
 > run on does not have PTYs, it won't have the testsuite either.

I see.

 > >  More generally I think its wrong to force
 > > the frontend to separate the output.  Currently, I get reasonable behaviour
 > > with Emacs without doing this and would always include interleaved output as a
 > > user option.
 > 
 > Would it hurt you to stitch them back together, though?  The fewer
 > interfaces we have to support, the better...

I guess it would even be safer in cases where the inferior has similar output
e.g debugging GDB itself.  However, I thought there were systems where ptys
weren't available (w32?).  Even if you can't run the testsuite, you might
still want to run GDB there (actually, I thought FSF GDB *is* being ported to
w32 - how is it tested?).

Nick
Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 1 Aug 2005 03:51

Re: MI testsuite to use PTY for inferior

On Mon, Aug 01, 2005 at 11:25:03AM +1200, Nick Roberts wrote:
>  > >  More generally I think its wrong to force
>  > > the frontend to separate the output.  Currently, I get reasonable behaviour
>  > > with Emacs without doing this and would always include interleaved output as a
>  > > user option.
>  > 
>  > Would it hurt you to stitch them back together, though?  The fewer
>  > interfaces we have to support, the better...
> 
> I guess it would even be safer in cases where the inferior has similar output
> e.g debugging GDB itself.  However, I thought there were systems where ptys

Yes, I agree.

> weren't available (w32?).  Even if you can't run the testsuite, you might
> still want to run GDB there (actually, I thought FSF GDB *is* being ported to
> w32 - how is it tested?).

Yes.  And, there, we are going to need a different solution.  Probably,
we would declare applications that use the console IO routines directly
unsupported, and run other applications via a pipe, allowing GDB to
capture input and output separately.  Lots of people are interested in
native Windows debugging - but not so many are interested in console
apps!

Speaking for CodeSourcery, we're only porting GDB to Windows _host_. So
it doesn't need much testing besides making sure the CLI works OK.  And
you can run expect under Cygwin to test a mingw32 GDB, which I hadn't
thought about in my previous message.  But we don't do that at the
moment.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 1 Aug 2005 03:53

Re: MI testsuite to use PTY for inferior

On Sun, Jul 31, 2005 at 05:20:21PM -0400, Bob Rossi wrote:
> What is GDB's stance on supporting target's via GDB/MI that can not support
> creating TTY's? Off the top of my head, I don't think it makes sense to
> support these targets. You can not write a reliable FE under theses
> circumstances. The inferior can spew out anything it chooses, including
> partial MI fragments (if inferior == GDB).
> 
> >   - As far as I know, native Win32 targets can't use PTYs:
> >       http://world.std.com/~jmhart/critcom.htm#UNIX%20Pseudoterminal
> >     So, they'll probably need something different.
> 
> In this scenario, I think Cygwin is the answer. Or use GDB/MI with an
> inferior program that doesn't output anything to the terminal.

That's probably what usually happens.  I don't know.  I can't say it's
a priority for me.

> >   - Remote targets that provide output currently aren't redirected onto
> >     the PTY; instead they'll appear interleaved, just like before.
> 
> In this scenario, I'm guessing from the sound of it that GDB just hasn't
> added support for this yet. So it's a GDB bug, right? I could look into
> this if I had some direction.

I don't know.  What do you want it to do?  GDB to set up a fake
terminal and push output to it?  Might make sense, might not, haven't
thought about it.

> > Also, Andrew pretty specifically asked you to leave the mi2-* tests
> > alone for this change.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Daniel Jacobowitz | 1 Aug 2005 03:55

Re: PATCH: tests for MI commands

On Mon, Aug 01, 2005 at 11:33:41AM +1200, Nick Roberts wrote:
>  > Second, I get a value of 0 here, but the test still fails. 
>  > func_ptr_struct and func_ptr_ptr aren't initialized either.  Chasing
>  > uninitialized members is going to leave the tests script a bit of a
>  > mess.
>  > 
>  > Initializing the whole structure proved to be a bit of a pain - these
>  > tests are ridiculously tricky to edit.  But here it is.  Tested on
>  > i686-pc-linux-gnu and committed.  I hope this will be more useful if we
>  > add any additional value-related tests.
> 
> I find the number of backslashes needed confusing (because of the read syntax
> for strings?).  Your changes seem concise.  I'll test these too.
>  
> Thanks again.

No problem.  About the backslashes:

If you say "\\\\" in TCL, then the parser will reduce it to the literal
string <\\>.  Then the regular expression parser will collapse that
down to a pattern which matches <\>.  {\\} is the same as "\\\\"
because backslashes aren't special to TCL inside of braces.

--

-- 
Daniel Jacobowitz
CodeSourcery, LLC
Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 1 Aug 2005 03:57

Re: PATCH: tests for MI commands

On Mon, Aug 01, 2005 at 11:17:32AM +1200, Nick Roberts wrote:
>  > > I would rather copy my changes to mi-stack.exp and mi-var-child.exp over to
>  > > mi2-stack.exp and mi2-var-child.exp.  Creating new files mi-var-cmd.c,
>  > > mi-basics.c etc seems more complicated.  Is this an acceptable short term
>  > > solution?
>  > 
>  > It's not complicated at all.  Please see the attached patch, which I've
>  > checked in.  It would be even simpler than this if folks had used
>  > ${srcfile} to begin with.
> 
> Well now some mi-*.exp files e.g mi-var-block.exp use var-cmd.c while
> others, namely mi-var-child.exp, use mi-var-child.c.  Clearly, though if
> you do the work its simpler (for me!).

Every other test in the testsuite (well, not true.  All the recent ones
anyway!) has its own source file.  We've found this to be the best
option - because really, most of the time when you change a source file
in the testsuite, it's so that you can add or improve tests, not fix
bugs in the programs being tested.  So duplication is less problematic
than the lockstep tangle that we encountered here.  So that's the
general principle.

> 
>  > Tested on i686-pc-linux-gnu, where it resolves 18 FAILs and assorted
>  > ERRORs.
> 
> Thanks.  I'll test them on my other machine, but I'm sure they will work.  I
> guess the idea is that mi2-*.exp tests shouldn't change although I'm still not
> convinced that they are useful - perhaps we can discuss that later.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Rossi | 1 Aug 2005 04:05

Re: MI testsuite to use PTY for inferior

> > >   - Remote targets that provide output currently aren't redirected onto
> > >     the PTY; instead they'll appear interleaved, just like before.
> > 
> > In this scenario, I'm guessing from the sound of it that GDB just hasn't
> > added support for this yet. So it's a GDB bug, right? I could look into
> > this if I had some direction.
> 
> I don't know.  What do you want it to do?  GDB to set up a fake
> terminal and push output to it?  Might make sense, might not, haven't
> thought about it.

Why doesn't GDB open a pty and simply give the FE the name of the device
it can read the inferior I/O from? This would simplify a lot of things.

Although, it still would not work nativly on Windows. However, if GDB
doesn't support inferior I/O on the host, it wouldn't be expected to
when using the remote target. The only difference is that only a Cygwin
port of GDB to windows would be able to support this feature, not a
Windows's part of GDB.

Thanks,
Bob Rossi
Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 1 Aug 2005 04:12

Re: [RFA] New testcase to evaluate Fortran substring expression

On Fri, Jul 15, 2005 at 06:25:02PM +0800, Wu Zhou wrote:
> Daniel,
> 
> I made some modification to the original patch.  The changes include:       
> 
> - Don't include "arglist :  arglist, subrange".  Because I don't figure   
> out how to evaluate multi-dimension array section yet.
> 
> - Only add a new operator: OP_F90_RANGE and get the range type wrapped by
> this operator.
> 
> - Change the name of new testcase from substring to subarray.  Because    
> g77 will handle string variable as character array instead. (gfortran did
> this too)  Added four tests for substring evaluation in gdb.fortran/exprs.exp, 
> the reason is that g77 and gfortran still treat string constant as string.
> 
> Please help review this too.  Thanks a lot!

This is looks very good!  Two comments for you:

  - The magic (and undocumented) constants are not a good idea.  Rather
    than being clever with abs(), how about using an enum saying what
    sort of range it is?

  - You have a bunch of lines which are too long in eval.c; could you
    fix that, please?

--

-- 
Daniel Jacobowitz
CodeSourcery, LLC
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 1 Aug 2005 04:15

Re: MI testsuite to use PTY for inferior

On Sun, Jul 31, 2005 at 10:05:25PM -0400, Bob Rossi wrote:
> > > >   - Remote targets that provide output currently aren't redirected onto
> > > >     the PTY; instead they'll appear interleaved, just like before.
> > > 
> > > In this scenario, I'm guessing from the sound of it that GDB just hasn't
> > > added support for this yet. So it's a GDB bug, right? I could look into
> > > this if I had some direction.
> > 
> > I don't know.  What do you want it to do?  GDB to set up a fake
> > terminal and push output to it?  Might make sense, might not, haven't
> > thought about it.
> 
> Why doesn't GDB open a pty and simply give the FE the name of the device
> it can read the inferior I/O from? This would simplify a lot of things.

Didn't we go through this already and decide it was better for the user
to provide the TTY and tell GDB where to send the user?  Just like we
do now for set inferior-tty?

It wouldn't be a big stretch to make this go for remote targets; GDB
would do the writing instead of the inferior.  There'd be no input.

For Windows, if someone cared to implement it, you could probably pass
a pipe to GDB in some fashion.  I do not know enough about Windows to
know how, or care enough about native Windows use of MI to figure it
out myself.

--

-- 
Daniel Jacobowitz
CodeSourcery, LLC
(Continue reading)

Permalink | Reply | 1 comment |

Gmane