Re: [RFA]: Fix partial symbol lookups

[Michael Snyder <msnyder@redhat.com>]

Daniel Berlin wrote:
> 
> Michael Snyder <msnyder@redhat.com> writes:
> 
> > Daniel Berlin wrote:
> >
> > > Correct.
> > > But this never worked since 1994 anyway, since psymbols have no
> > > demangled name in them.
> > > :)
> >
> > Good catch!  I too remember the comments that imply that
> > mangled names are in there, and have assumed they were true.
> 
> Mangled names are, demangled names aren't.
> I think that's what you meant, I mix up the terms all the time.

Yes, that's what I meant.  ;-(

> I thought the same thing, until Peter pointed out I was wrong. :)
> 
> >
> > >
> > > I also corrected lookup_partial_symbol to binary search the global
> > > table, regardless of language, since this is the part that had led me
> > > to believe it had demangled names in it in the first place.
> >
> > Are you SURE that NO language puts mangled names in?
> You mean demangled, and yes, i'm positive.

Ah, but now Peter points out that this might not be true for HP.

> > > no reason to linear search it, ever.
> > > Statics still aren't sorted, so we linear search those.
> >
> > Hmmm -- so why not sort the statics?
> 
> Usually there aren't enough to matter, I believe.
> I think that was the reasoning, anyway.

That's not good reasoning.  How many there are
depends solely on programmer's style.  How difficult
would it be to sort the list and search it sensably?
Seems like except for the initial investment of implementing
it, this would be a win for complexity, since globals and
statics would no longer have to be handled differently.
From kevinb@cygnus.com Wed Nov 15 12:01:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [PATCH RFC] Protoize win32-nat.c, xcoffread.c
Date: Wed, 15 Nov 2000 12:01:00 -0000
Message-id: <1001115200143.ZM14976@ocotillo.lan>
References: <1001110012636.ZM28396@ocotillo.lan> <kevinb@cygnus.com>
X-SW-Source: 2000-11/msg00176.html
Content-length: 386

On Nov 9,  6:26pm, Kevin Buettner wrote:

> 	* win32-nat.c (safe_symbol_file_add): Remove extraneous blank
> 	line after function declarator.
> 	* xcoffread.c (arrange_linetable, xcoff_initial_scan): Protoize.

Committed.

(The win32-nat.c note was omitted at Chris Faylor's request.)

Also, I removed an extraneous blank line that had crept into
ChangeLog itself in the last few days.
From taylor@cygnus.com Wed Nov 15 12:14:00 2000
From: David Taylor <taylor@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Cc: msnyder@cygnus.com
Subject: [RFA] trace_find_tracepoint_command bug fix
Date: Wed, 15 Nov 2000 12:14:00 -0000
Message-id: <200011152013.PAA27020@texas.cygnus.com>
X-SW-Source: 2000-11/msg00177.html
Content-length: 431

In trace_find_tracepoint_command (tracepoint.c), we find the line:

	tdp = parse_and_eval_address (args);

Since the tdp is just an integer, I'd like to change that to instead
read:

	tdp = parse_and_eval_long (args);

The ChangeLog entry would be:

	* tracepoint.c (trace_find_tracepoint_command): Replace call to
	parse_and_eval_address with a call to parse_and_eval_long as
	we are evaluating an integer, not an address.

David
From msnyder@redhat.com Wed Nov 15 12:18:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: David Taylor <taylor@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com, msnyder@cygnus.com
Subject: Re: [RFA] trace_find_tracepoint_command bug fix
Date: Wed, 15 Nov 2000 12:18:00 -0000
Message-id: <3A12EF9C.4DD7@redhat.com>
References: <200011152013.PAA27020@texas.cygnus.com>
X-SW-Source: 2000-11/msg00178.html
Content-length: 623

David Taylor wrote:
> 
> In trace_find_tracepoint_command (tracepoint.c), we find the line:
> 
>         tdp = parse_and_eval_address (args);
> 
> Since the tdp is just an integer, I'd like to change that to instead
> read:
> 
>         tdp = parse_and_eval_long (args);
> 
> The ChangeLog entry would be:
> 
>         * tracepoint.c (trace_find_tracepoint_command): Replace call to
>         parse_and_eval_address with a call to parse_and_eval_long as
>         we are evaluating an integer, not an address.

Yup, please go ahead.  Actually, I thought you'd 
already done this.  Is this one that got away the first time?
From kevinb@cygnus.com Wed Nov 15 12:19:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [PATCH RFC] Protoize wrapper.c
Date: Wed, 15 Nov 2000 12:19:00 -0000
Message-id: <1001115201906.ZM15013@ocotillo.lan>
X-SW-Source: 2000-11/msg00179.html
Content-length: 1061

Ahem...

The following bit of protoization *should* have been done by the
person who recently added the functions in question.

(I reran my protoization checker script to see what else remained
to be done and it turned up this file, in addition to several others
that I had been waiting on.)

	* wrapper.c (gdb_value_assign, wrap_value_assign): Protoize.

Index: wrapper.c
===================================================================
RCS file: /cvs/src/src/gdb/wrapper.c,v
retrieving revision 1.9
diff -u -r1.9 wrapper.c
--- wrapper.c	2000/11/06 23:12:29	1.9
+++ wrapper.c	2000/11/15 20:13:13
@@ -169,10 +169,7 @@
 }
 
 int
-gdb_value_assign (val1, val2, result)
-     value_ptr val1;
-     value_ptr val2;
-     value_ptr *result;
+gdb_value_assign (value_ptr val1, value_ptr val2, value_ptr *result)
 {
   struct gdb_wrapper_arguments args;
 
@@ -191,8 +188,7 @@
 }
 
 static int
-wrap_value_assign (a)
-     char *a;
+wrap_value_assign (char *a)
 {
   struct gdb_wrapper_arguments *args = (struct gdb_wrapper_arguments *) a;
   value_ptr val1, val2;