[commit/testsuite] subst.exp: Empty message (3rd parameter) in call to gdb_test

Hello,

This is something that Michael spotted and reported to me. Definitely
a mistake, causing the test to report no status...

gdb/testsuite:
2010-05-31  Joel Brobecker  <brobecker <at> adacore.com>

        * gdb.base/subst.exp: Fix call to gdb_test with empty message.

Tested on x86_64-linux.  The test now reports 30 PASSes instead of 29.
Checked in.

---
 gdb/testsuite/ChangeLog          |    4 ++++
 gdb/testsuite/gdb.base/subst.exp |    2 +-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index c96b4e0..5d50914 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
 <at>  <at>  -1,3 +1,7  <at>  <at> 
+2010-05-31  Joel Brobecker  <brobecker <at> adacore.com>
+
+	* gdb.base/subst.exp: Fix call to gdb_test with empty message.
+
 2010-05-31  Jan Kratochvil  <jan.kratochvil <at> redhat.com>

 	Accept the new Linux kernel "t (tracing stop)" string.

[RFC] windows-nat.c: New oddity after copy console information for new console patch.

> -----Message d'origine-----
> De : gdb-patches-owner <at> sourceware.org [mailto:gdb-patches-
> owner <at> sourceware.org] De la part de Christopher Faylor
> Envoyé : Sunday, May 30, 2010 7:11 PM
> À : gdb-patches <at> sourceware.org; Pierre Muller
> Objet : Re: [RFA] windows-nat.c: Copy console information for new
> console
> 
> On Fri, May 28, 2010 at 12:16:59PM +0200, Pierre Muller wrote:
> >> >> From Christopher Faylor
> >> >> I actually thought fairly carefully about flags.  If you have a
> >> >> function
> >> >> which controls console info, then the function should set the
> flags
> >> >> appropriately to deal with the console info.
> >> >
> >> >
> >> >  As you prefer,
> >> >here is a new version that also takes DWORD *flags as parameter.
> >> >  I also tried to explain a little bit better
> >> >what the function tries to do.
> >>
> >> Thanks.  Looks good.  I forgot to say:  Thanks for doing this.  It
> >> looks like
> >> a nice improvement.
> >
> >  Hi Christopher,
> >  does this mean that you want to test it
> >a little bit more before you give some more detailed

[gdbserver] avoid nested strtok calls in handling of qSupported

target_process_qsupported may, (and does so on linux x86, ) call
strtok to split the xmlRegisters=foo,bar feature string.  Nesting
strtok (str,...) calls is a no-no, since the inner strtok messes
up the global state of the outer call.

(This happened to go unnoticed because gdb was sending
multiprocess+;xmlRegisters=... in that order.  I noticed the breakage
since gdb is now sending "multiprocess+;xmlRegisters=...;qRelocInsn+"
and the outer strtok was failing to see the qRelocInsn+ token.)

Applied.

--

-- 
Pedro Alves

2010-06-01  Pedro Alves  <pedro <at> codesourcery.com>

	* server.c (handle_query) <qSupported>: Do two passes over the
	qSupported string to avoid nesting strtok.

---
 gdb/gdbserver/server.c |   48 ++++++++++++++++++++++++++++++++++--------------
 1 file changed, 34 insertions(+), 14 deletions(-)

Index: src/gdb/gdbserver/server.c
===================================================================
--- src.orig/gdb/gdbserver/server.c	2010-06-01 12:55:52.000000000 +0100
+++ src/gdb/gdbserver/server.c	2010-06-01 13:41:39.000000000 +0100
 <at>  <at>  -1346,20 +1346,40  <at>  <at>  handle_query (char *own_buf, int packet_
 	 feature will follow a ':', and latter features will follow

Re: GDBserver fast tracepoints support

On Thursday 06 May 2010 04:30:28, Pedro Alves wrote:
> This patch adds support of fast dynamic jump-based tracepoints support
> to 32-bit and 64-bit x86 linux GDBserver.

I've checked this in, as below.

> [NEWS and docs patch bits included.  Are those okay?]

These had been split into a separate thread, and Eli approved
them (with minor tweaks, that have been addressed).

> Instead of teaching GDBserver about that, the patch adds a new packet
> to the remote protocol --- qRelocInsn, that GDBserver and other stubs
> can use to ask GDB to do the work instead.

This had been split as an independent patch meanwhile, and had already
been checked in.

--

-- 
Pedro Alves

gdb/gdbserver/
2010-06-01  Pedro Alves  <pedro <at> codesourcery.com>
	    Stan Shebs  <stan <at> codesourcery.com>

	* Makefile.in (IPA_DEPFILES, extra_libraries): New.
	(all): Depend on $(extra_libraries).
	(install-only): Install the IPA.
	(IPA_OBJS, IPA_LIB): New.
	(clean): Remove the IPA lib.

[PATCH] matrix prettyprinting

This is a small patch to libstdc++-v3/python/libstdcxx/v6/printers.py 
that goes with a matrix prettyprinter in gdb.

Chris Moller

[patch] Fix ADL anonymous type crash

If one attempts to make an inferior function call with an anonymous type 
gdb will crash in make_symbol_overload_list_adl_namespace because the 
type has no name. This patch fixes and tests that scenario.

Thanks,
   Sami

2010-06-01  Sami Wagiaalla  <swagiaal <at> redhat.com>

	* cp-support.c (make_symbol_overload_list_adl_namespace): Handle
	anonymous type case.

2010-06-01  Sami Wagiaalla  <swagiaal <at> redhat.com>

	* gdb.cp/koenig.exp: Added new test case.
	* gdb.cp/koenig.cc: Ditto.

diff --git a/gdb/cp-support.c b/gdb/cp-support.c
index 8f447ca..5c7b80a 100644
--- a/gdb/cp-support.c
+++ b/gdb/cp-support.c
 <at>  <at>  -752,6 +752,9  <at>  <at>  make_symbol_overload_list_adl_namespace (struct type *type,

   type_name = TYPE_NAME (type);

+  if (type_name == NULL)
+    return;
+
   prefix_len = cp_entire_prefix_len (type_name);

[rfc patch] nomem: internal_error -> error

Hi,

unfortunately I see this problem reproducible only with the
archer-jankratochvil-vla branch (VLA = Variable Length Arrays - char[var]).
OTOH this branch I hopefully submit in some form for FSF GDB later.

In this case (a general problem but tested for example on Fedora 13 i686):

int
main (int argc, char **argv)
{
  char a[argc];
  return a[0];
}

(gdb) start
(gdb) print a
../../gdb/utils.c:1251: internal-error: virtual memory exhausted: can't allocate 4294951689 bytes.

It is apparently because boundary for the variable `a' is not initialized
there.  Users notice it due to Eclipse-CDT trying to automatically display all
the local variables on each step.

Apparentl no regressions on {x86_64,x86_64-m32,i686}-fedora13-linux-gnu.
But is anone aware of the reasons to use internal_error there?
I find simple error as a perfectly reasonable there.
(history only tracks it since the initial import)

IIRC this idea has been discussed with Tom Tromey, not sure of its origin.

[obv] testsuite: Remove sent trailing newlines

Hi,

the gdb.base/commands.exp change has no effect, empty leading line in the GDB
commands list gets ignored.  But it was IMO apparently excessive / by mistake.

The gdb.mi/mi-nsintrall.exp is also harmless, empty line in MI mode will
generate just some additional output like:
(gdb) 

&"\n"
^done
(gdb) 

But the gdb.java/jmisc.exp change is a racy FAIL fix causing:
p *args^M
^M
$2 = {length: 0}^M
(gdb) ^M
$3 = {length: 0}^M
(gdb) FAIL: gdb.java/jmisc.exp: p *args

Checked-in.

Thanks,
Jan

http://sourceware.org/ml/gdb-cvs/2010-06/msg00004.html

--- src/gdb/testsuite/ChangeLog	2010/05/31 23:20:19	1.2295
+++ src/gdb/testsuite/ChangeLog	2010/06/01 17:22:32	1.2296

Re: RFC: partially fix empty DW_OP_piece

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil <at> redhat.com> writes:

We were talking on irc and Jan asked for more information about part of
my plan...

Tom> The other way is to simply remove val_print entirely and make all of
Tom> printing work using values.  I think this is the route I would prefer.

Jan> That could hopefully solve the problem of missing type-associated object
Jan> address for DW_OP_push_object_address for the VLA (variable length arrays)
Jan> patch.

I am curious to know what you need here.

I started by looking briefly at replacing val_print.  This looks pretty
big, though.  So I looked into other solutions.

I wrote a big patch to pass lval_funcs through all the val_print code.
However, it turns out that this is not sufficient: the code has to
handle value_offset() as well, which means either adding another
argument (the offset) or just passing the original value through.

So, currently I am thinking I will go through my existing patch and have
it pass a value instead of lval_funcs.  Of course this means a lot of
redundant info, which is ugly.

There are barriers to removing val_print.  I think the biggest one,
conceptually, is that recursion in val_print means making new values,
which means copying the value contents.  This can be expensive.  (Of
course there are solutions to that, reference counting the value

Re: [rfc patch] nomem: internal_error -> error

> Date: Tue, 1 Jun 2010 18:48:08 +0200
> From: Jan Kratochvil <jan.kratochvil <at> redhat.com>
> 
> Hi,
> 
> unfortunately I see this problem reproducible only with the
> archer-jankratochvil-vla branch (VLA = Variable Length Arrays - char[var]).
> OTOH this branch I hopefully submit in some form for FSF GDB later.
> 
> In this case (a general problem but tested for example on Fedora 13 i686):
> 
> int
> main (int argc, char **argv)
> {
>   char a[argc];
>   return a[0];
> }
> 
> (gdb) start
> (gdb) print a
> ../../gdb/utils.c:1251: internal-error: virtual memory exhausted: can't allocate 4294951689 bytes.
> 
> I find simple error as a perfectly reasonable there.

I disagree; this internal-error really is a bug in GDB.  We should
never try to allocate that much memory.