From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: Daniel Berlin Cc: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: [RFA]: Fix partial symbol lookups Date: Wed, 15 Nov 2000 11:19:00 -0000 Message-id: <3A12E1CD.4BA2@redhat.com> References: <3A12C01A.659A@redhat.com> X-SW-Source: 2000-11/msg00175.html Daniel Berlin wrote: > > Michael Snyder 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 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> 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 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 To: David Taylor 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 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;