patch for crash in d-lang.c's demangler

There's a minor, but important bug in the d language symbol demangler.  I
haven't reviewed the whole thing for other bugs, just the one that I hit.

I don't have a copyright assignment form on file, but hopefully this diff is
small enough to not require one.  Consider the patch public domain or whatever
if that helps.

diff --git a/gdb/d-lang.c b/gdb/d-lang.c
index 6db521b..f17431b 100644
--- a/gdb/d-lang.c
+++ b/gdb/d-lang.c
 <at>  <at>  -37,8 +37,9  <at>  <at>  extract_identifiers (const char *mangled_str, struct obstack
*tempbuf)

   while (isdigit (*mangled_str))
     {
-      i = strtol (mangled_str, NULL, 10);
-      mangled_str++;
+      char * end_ptr;
+      i = strtol (mangled_str, &end_ptr, 10);
+      mangled_str = end_ptr;
       if (i <= 0  && strlen (mangled_str) < i)
         return 0;
       obstack_grow (tempbuf, mangled_str, i);

Before this change, symbols with string fragments over 9 bytes long gets into a
bad state and might end up crashing.  Certainly ends up with a bad string.

And example that crashes for me:
    20src/core/atomic.d.9215__unittest_failFiZv

Re: [patch] gdb.base/*.exp: Do not expect full paths to file names.

On Saturday 31 July 2010 01:03:39, Kazu Hirata wrote:
> Attached is a patch to adjust break-always.exp and commands.exp to
> stop expecting full paths to file names.
> 
> Without this patch, these testcases fail on sparc-solaris2.8.

(I think the relevance is remote host testing)

> 
> Tested on sparc-solaris2.8.  OK to apply?

Okay.

--

-- 
Pedro Alves

Re: [0/4] RFC: add DWARF index support

On Fri, Jul 30, 2010 at 1:46 PM, Tom Tromey <tromey <at> redhat.com> wrote:
> [...]
> Index: gdb-add-index.sh
> ===================================================================
> RCS file: gdb-add-index.sh
> diff -N gdb-add-index.sh
> --- /dev/null   1 Jan 1970 00:00:00 -0000
> +++ gdb-add-index.sh    30 Jul 2010 20:45:30 -0000
>  <at>  <at>  -0,0 +1,29  <at>  <at> 
> +#! /bin/sh
> +
> +# Add a .gdb_index section to a file.
> +
> +# Copyright (C) 2010 Free Software Foundation, Inc.
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program.  If not, see <http://www.gnu.org/licenses/>.
> +
> +file="$1"
> +dir="${file%/*}"
> +

Re: [RFA] stdio gdbserver connection

On Tue, Jun 8, 2010 at 10:27 AM, Daniel Jacobowitz <dan <at> codesourcery.com> wrote:
> On Tue, May 25, 2010 at 10:27:15AM -0700, Doug Evans wrote:
>> Hi.
>>
>> This patch lets gdbserver communicate via stdio.
>>
>> E.g.
>>
>> (gdb) target remote | ssh -T myhost gdbserver stdio hello
>
> Silly thing to comment about but... "-" instead to mean stdio?

Sure.  I avoided it but I don't have a strong preference.

>> One outstanding issue is what to do with inferior stdio.
>> stderr is ok, it'll just get propagated back to gdb which will display it.
>> But we don't want inferior stdio to interfere with the gdb connection.
>
> Send it to a pipe, pass it to GDB over semihosting?

Does semihosting work with non-stop mode?

An alternative, I think, is to redirect the inferior's stdout,stderr
to gdbserver's stderr, and redirect stdin to /dev/null (say).
That feels like more of a hack than explicitly handling inferior stdio.
But it's simpler, or at least should be theoretically ... alas when
gdbserver is starting it calls start_inferior before remote_open, and
thus unless one makes the chosen kind of connection known before
remote_open is called (or passes "port" to start_inferior, blech),
it's a non-starter.  Sigh.

[commit] dwarf2read.c (dwarf_attr_name): Add DW_AT_GNU_odr_signature.

Hi.

I've committed the following.

According to include/dwarf2.h there are more GNU attributes,
I left them for another pass.

2010-08-02  Doug Evans  <dje <at> google.com>

	* dwarf2read.c (dwarf_attr_name): Add DW_AT_GNU_odr_signature.

Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.432
diff -u -p -r1.432 dwarf2read.c
--- dwarf2read.c	28 Jul 2010 20:05:03 -0000	1.432
+++ dwarf2read.c	3 Aug 2010 00:50:04 -0000
 <at>  <at>  -11379,6 +11379,8  <at>  <at>  dwarf_attr_name (unsigned attr)
       return "DW_AT_body_end";
     case DW_AT_GNU_vector:
       return "DW_AT_GNU_vector";
+    case DW_AT_GNU_odr_signature:
+      return "DW_AT_GNU_odr_signature";
     /* VMS extensions.  */
     case DW_AT_VMS_rtnbeg_pd_address:
       return "DW_AT_VMS_rtnbeg_pd_address";

Subject: Re: [PATCH] Bug 10645: small additions to existing testcase

Re: [PATCH] Bug 10645: small additions to existing testcase

On Fri, Jul 30, 2010 at 11:13 PM, Dragos Tatulea
<dragos.tatulea <at> gmail.com> wrote:
> Hi,
>
>    The original testcase has been done by Jan Kratochvil, added in
> the bug details. I just added a few extra lines.
>    This bug has been partially fixed by another change (please check
> bug description for more details). After the commit mentioned in the
> bug, the test is passing. That's because invalid watchpoints are
> catched on access instead of mmap/munmap.
>
Forgot to attach the patch.

Thanks,
Dragos Tatulea

---
 gdb/testsuite/gdb.base/watchpoint-hw-unreadable.c  |   45 +++++++
 .../gdb.base/watchpoint-hw-unreadable.exp          |  127 ++++++++++++++++++++
 2 files changed, 172 insertions(+), 0 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/watchpoint-hw-unreadable.c
 create mode 100644 gdb/testsuite/gdb.base/watchpoint-hw-unreadable.exp

diff --git a/gdb/testsuite/gdb.base/watchpoint-hw-unreadable.c b/gdb/testsuite/gdb.base/watchpoint-hw-unreadable.c
new file mode 100644
index 0000000..887c293
--- /dev/null
+++ b/gdb/testsuite/gdb.base/watchpoint-hw-unreadable.c
 <at>  <at>  -0,0 +1,45  <at>  <at> 

[RFA]corelow.c: Add tid to add_to_thread_list

Hi,

I found that from gdb 7.1 to gdb-cvs-head cannot analyze the core file
that get from kdump.
What I got:
[New <main task>]
[New Thread 2719]
../../src/gdb/thread.c:884: internal-error: switch_to_thread:
Assertion `inf != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
That is because:
 objdump -h ./vmcore

./vmcore:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 note0         00000a48  0000000000000000  0000000000000000  00000238  2**0
                  CONTENTS, READONLY
  1 .reg/0        000000d8  0000000000000000  0000000000000000  000002bc  2**2
                  CONTENTS
  2 .reg          000000d8  0000000000000000  0000000000000000  000002bc  2**2
                  CONTENTS
  3 .reg/2719     000000d8  0000000000000000  0000000000000000  00000420  2**2
                  CONTENTS
  4 .reg/0        000000d8  0000000000000000  0000000000000000  00000584  2**2
                  CONTENTS
  5 .reg/0        000000d8  0000000000000000  0000000000000000  000006e8  2**2

Re: [patch] Allow gdb.Values to become callable if appropriate.

On 31/07/10 08:07, Eli Zaretskii wrote:
>> X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,
>> 	T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
>> From: Tom Tromey <tromey <at> redhat.com>
>> Cc: gdb-patches <at> sourceware.org, Eli Zaretskii <eliz <at> gnu.org>
>> Date: Fri, 30 Jul 2010 15:39:29 -0600
>>
>>>>>>> "Phil" == Phil Muldoon <pmuldoon <at> redhat.com> writes:
>>
>> Phil> Here is a patch.  What do you think?
>>
>> It looks reasonable to me, but please wait for Eli to comment.
> 
> It's fine.
> 
> Thanks.

FYI I checked this patch in.

http://sourceware.org/ml/gdb-cvs/2010-08/msg00009.html

Cheers,

Phil

Re: [RFA] remote-sim.c: Add support for multiple sim instances

Pong. 

Comments inline below.

On Friday 02 July 2010 23:30:17, Kevin Buettner wrote:

> Index: remote-sim.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/remote-sim.c,v
> retrieving revision 1.96
> diff -u -p -r1.96 remote-sim.c
> --- remote-sim.c	16 May 2010 21:11:14 -0000	1.96
> +++ remote-sim.c	2 Jul 2010 20:15:59 -0000
>  <at>  <at>  -101,19 +101,125  <at>  <at>  void simulator_command (char *args, int 
>  /* Forward data declarations */
>  extern struct target_ops gdbsim_ops;
>  
> -static int program_loaded = 0;
> +static const struct inferior_data *sim_inferior_data_key;
>  
> -/* We must keep track of whether the simulator has been opened or not because
> -   GDB can call a target's close routine twice, but sim_close doesn't allow
> -   this.  We also need to record the result of sim_open so we can pass it
> -   back to the other sim_foo routines.  */
> -static SIM_DESC gdbsim_desc = 0;
> -
> -/* This is the ptid we use while we're connected to the simulator.
> -   Its value is arbitrary, as the simulator target don't have a notion
> -   or processes or threads, but we need something non-null to place in
> -   inferior_ptid.  */

Re: [patch] Implement post_event for Python scripts.

On 30/07/10 22:42, Tom Tromey wrote:
>>>>>> "Joel" == Joel Brobecker <brobecker <at> adacore.com> writes:
> 
>>> Providing an example of a multi-threaded python script using
>>> post_event would be too complex for the manual (I'm not sure that was
>>> what you wanted anyway).  I provided a small example that shows usage.
>>> Is this okay?
> 
> Joel> I'm just trying to figure out how this feature can be useful, and
> Joel> in particular when the callbacks are triggered. Perhaps, rather than
> Joel> an example, what we need is a section that describes the event loop
> Joel> and when it is queried.

It's not useful to single-threaded scenarios (which I think are
going to be the vast number of applications of Python scripting).  For
multi-threaded scenarios (say a UI running on top of GDB that has its
own UI thread and event-loop) this is the only thread-safe way to
interact with GDB.  Describing the GDB even-loop would seem to be more
the province of an internals manual.  That being said, I take your point.

> Tom> For the purposes of post_event, I think it is probably sufficient to say
> Tom> that the callback will be executed in the main thread "sometime".  I
> Tom> don't think we can really provide anything more concrete than that
> Tom> anyhow.

I wrote up a multi-threaded example, but it is still a very basic
shell of an example.  To really show a useful  example it would require
loading an inferior, etc., and that would probably be too in-depth for
the manual