Re: [RFA]: Fix partial symbol lookups

Re: [RFA]: Fix partial symbol lookups

[Peter.Schauer]

> > The previous version of lookup_partial_symbol (before your changes) would
> > have found both mangled and demangled names.
> 
> Now this I take issue with.
> How could it possibly find demangled names, if it doesn't have access
> to them?
> lookup_partial_symbol didn't find demangled names before my patch on
> 10-12. It doesn't have the code to do so, as you pointed out yourself
> (because the SYMBOL_MATCHES_NAME is no better than the strcmp, since
> we have no access to demangled names), unless the symbol name was the
> demangled name, rather than the mangled name, which doesn't occur.

Not true.
There were no demangled names in partial symbols from most symbol readers,
_except_ for the HP reader, which we are currently discussing, and which
I discovered rather late in the day as well.
Before your change, lookup_partial_symbol fell back to a linear search
if it didn't find the symbol and had the chance to find the demangled symbol
via SYMBOL_MATCHES_NAME during the linear search.

> > As a starter, the problems mentioned in
> > http://sources.redhat.com/ml/gdb-patches/2000-10/msg00230.html
> > http://sources.redhat.com/ml/gdb-patches/2000-10/msg00247.html
> > http://sources.redhat.com/ml/gdb-patches/2000-10/msg00248.html
> > http://sources.redhat.com/ml/gdb-patches/2000-10/msg00220.html
> > are still not addressed. 
> 
> The first one includes a patch, as soon as it's approved, it'll be
> applied.

And which will have to be adapted to your patches. Which will mean more
work for me, now that I am responsible for fixing _your_ bug because _I_
submitted the RFA, right ?

> The second one points out things this patch fixes.

No, it contains an example which is not fixed after the infinite regression
gets fixed. Please read the message again and then try the example with
any combination of suggested fixes you like. It will not work.

> The third one is the same.

No, it points out another problem with `maint check'. Have you ever tried it
with your patches ?

> The fourth one has to do with makefile tweaking, so i have no clue
> what that has to do with anything.

Sorry, typo, I meant
http://sources.redhat.com/ml/gdb-patches/2000-10/msg00250.html
I've also submitted a patch for that one though. It is the easiest to fix,
and it seems that I will have to take care of that one as well ?

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From dberlin@redhat.com Thu Nov 16 08:36:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
Cc: msnyder@redhat.com, jimb@cygnus.com, gdb-patches@sources.redhat.com, ezannoni@cygnus.com
Subject: Re: [RFA]: Fix partial symbol lookups
Date: Thu, 16 Nov 2000 08:36:00 -0000
Message-id: <m38zqj3mcb.fsf@dan2.cygnus.com>
References: <200011161222.NAA05985@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-11/msg00205.html
Content-length: 2046

"Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de> writes:

> Dan, have you looked at the HPUXHPPA defines in lookup_symbol ?
> These make me believe that the HP reader indeed needs lookups on partial
> symbols.
> 
> In this case, you have a problem when lookup_symbol is called with e.g.
> overload1arg(int) (when we want to set a breakpoint at the function in
> cplusfuncs).
> 
> As lookup_symbol_aux has no access to the mangled name, a lookup in the
> partial symbols will fail, as you are looking for a demangled name in the
> mangled names.
> The previous version of lookup_partial_symbol (before your changes) would
> have found both mangled and demangled names.

And just for the record, this is wrong, and the source of many
annoying bugs i've tried to track down (such as where we would or wouldn't find a C++
operator symbol depending on when you tried to call
it. lookup_partial_symbol wouldn't find it, but lookup_symbol and
lookup_minimal_symbol would.).

I grabbed gdb-5.0 source, which certainly does not have my changes in
it, and lo and behold, it doesn't find demangled names in partial
symbols. Try it yerself if you like.

It's possible this is because of your change in 1994 to make partial
symbols no longer have demangled names.
But we certainly no longer find demangled names in partial symbols,
since at least 5 months before my changes.
In fact, I was actually of the impression that we weren't supposed to, since we
never have since as long as i've been working on GDB.
If lookup_partial_symbol is supposed to be able to find demangled
names, then it needs access to the demangled names, which partial
symbols don't have.
We'd either have to transform demangled names back into mangled ones,
or include demangled names in partial symbols, to have this work..

Alternatively, you could SYMBOL_INIT_DEMANGLED_NAME in
lookup_partial_symbol, before calling SYMBOL_MATCHES_NAME.

but SYMBOL_MATCHES_NAME won't ever see a demangled name on the partial
symbols, and thus, never find a demangled name.


--Dan

Re: [RFA]: Fix partial symbol lookups

[Daniel Berlin]

"Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de> writes:

> > > The previous version of lookup_partial_symbol (before your changes) would
> > > have found both mangled and demangled names.
> > 
> > Now this I take issue with.
> > How could it possibly find demangled names, if it doesn't have access
> > to them?
> > lookup_partial_symbol didn't find demangled names before my patch on
> > 10-12. It doesn't have the code to do so, as you pointed out yourself
> > (because the SYMBOL_MATCHES_NAME is no better than the strcmp, since
> > we have no access to demangled names), unless the symbol name was the
> > demangled name, rather than the mangled name, which doesn't occur.
> 
> Not true.
> There were no demangled names in partial symbols from most symbol readers,
> _except_ for the HP reader, which we are currently discussing, and which
> I discovered rather late in the day as well.
> Before your change, lookup_partial_symbol fell back to a linear search
> if it didn't find the symbol and had the chance to find the demangled symbol
> via SYMBOL_MATCHES_NAME during the linear search.

I'll happily make it linear search on HPUX, as soon as HP confirms
it's necessary.

> 
> > > As a starter, the problems mentioned in
> > > http://sources.redhat.com/ml/gdb-patches/2000-10/msg00230.html
> > > http://sources.redhat.com/ml/gdb-patches/2000-10/msg00247.html
> > > http://sources.redhat.com/ml/gdb-patches/2000-10/msg00248.html
> > > http://sources.redhat.com/ml/gdb-patches/2000-10/msg00220.html
> > > are still not addressed. 
> > 
> > The first one includes a patch, as soon as it's approved, it'll be
> > applied.
> 
> And which will have to be adapted to your patches. Which will mean more
> work for me, now that I am responsible for fixing _your_ bug because _I_
> submitted the RFA, right ?

No, I'll clean it up if you like. Assuming you don't want me to just
revert all the 10-12 changes and be done with it.


> 
> > The second one points out things this patch fixes.
> 
> No, it contains an example which is not fixed after the infinite regression
> gets fixed. Please read the message again and then try the example with
> any combination of suggested fixes you like. It will not work.
> 
I meant the patch I submitted, that is in the subject line ([RFA]: Fix
partial symbol lookups)

> > The third one is the same.
> 
> No, it points out another problem with `maint check'. Have you ever tried it
> with your patches ?

Yes, I have.
(gdb) maintenance check-symtabs 
During symbol reading, type qualifier 'const' ignored.
During symbol reading, unsupported stack op: 'DW_OP_deref_size'.
During symbol reading, type qualifier 'volatile' ignored.
(gdb)


> 
> > The fourth one has to do with makefile tweaking, so i have no clue
> > what that has to do with anything.
> 
> Sorry, typo, I meant
> http://sources.redhat.com/ml/gdb-patches/2000-10/msg00250.html
> I've also submitted a patch for that one though. It is the easiest to fix,
> and it seems that I will have to take care of that one as well ?

As I said about the first patch, i'll take care of it, assuming you
don't want me to just revert all the changes.
--Dan

Re: [RFA]: Fix partial symbol lookups

[Peter.Schauer]

> No, I'll clean it up if you like. Assuming you don't want me to just
> revert all the 10-12 changes and be done with it.

This decision has to be made by the symtab maintainers of course.

> > No, it points out another problem with `maint check'. Have you ever tried it
> > with your patches ?
> 
> Yes, I have.
> (gdb) maintenance check-symtabs 
> During symbol reading, type qualifier 'const' ignored.
> During symbol reading, unsupported stack op: 'DW_OP_deref_size'.
> During symbol reading, type qualifier 'volatile' ignored.
> (gdb)

Well, with gcc-2.95.2 -ggdb on a linux x86 box I get

(gdb) maint check
During symbol reading, type qualifier 'const' ignored.
During symbol reading, type qualifier 'volatile' ignored.
During symbol reading, type qualifier 'const' ignored.
Global symbol `__24Contains_static_instanceii' only found in misc.cc psymtab
Global symbol `__31Contains_nested_static_instanceii' only found in misc.cc psym
tab
Global symbol `__3Bariii' only found in misc.cc psymtab
Global symbol `__3Fooii' only found in misc.cc psymtab
Global symbol `__5Base1i' only found in misc.cc psymtab
Global symbol `__Q231Contains_nested_static_instance6Nestedi' only found in misc
.cc psymtab
Global symbol `__opi__3Foo' only found in misc.cc psymtab
Global symbol `foo__C22const_vol_method_classRi' only found in misc.cc psymtab
Global symbol `times__3Fooi' only found in misc.cc psymtab

which is not surprising, because maintenance_check_symtabs calls
lookup_block_symbol with the mangled symbol name.
Perhaps you have applied more patches to your source tree...

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From dberlin@redhat.com Thu Nov 16 09:16:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: gdb-patches@sources.redhat.com
Cc: Peter Schauer <Peter.Schauer@regent.e-technik.tu-muenchen.de>, jimb@redhat.com
Subject: [PATCH] revert 10-12 changes
Date: Thu, 16 Nov 2000 09:16:00 -0000
Message-id: <m3d7fv263i.fsf@dan2.cygnus.com>
X-SW-Source: 2000-11/msg00211.html
Content-length: 6925

Since these changes have been the bane of my existence, i'd like to
revert them.

Maybe in a few {weeks,months,years}, i'll make another go at it.

The attached should do this, but I left the division between
lookup_symbol and lookup_symbol_aux, since it seemed to make sense
(i'll revert this too if someone wants it the old way).

I also fixed the infinite recursion caused by this renaming, that Peter
had submitted a patch for.

Can someone look this over, and tell me if I missed anything? I went
by my submitted patch, but i've got a massive headache this morning,
so i may have missed something accidently.


--Dan

Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.20
diff -c -3 -p -r1.20 symfile.c
*** symfile.c	2000/10/27 15:02:42	1.20
--- symfile.c	2000/11/16 17:06:36
*************** compare_symbols (const PTR s1p, const PT
*** 212,218 ****
  
    s1 = (struct symbol **) s1p;
    s2 = (struct symbol **) s2p;
!   return (STRCMP (SYMBOL_SOURCE_NAME (*s1), SYMBOL_SOURCE_NAME (*s2)));
  }
  
  /*
--- 212,218 ----
  
    s1 = (struct symbol **) s1p;
    s2 = (struct symbol **) s2p;
!   return (STRCMP (SYMBOL_NAME (*s1), SYMBOL_NAME (*s2)));
  }
  
  /*
*************** compare_psymbols (const PTR s1p, const P
*** 245,252 ****
  
    s1 = (struct partial_symbol **) s1p;
    s2 = (struct partial_symbol **) s2p;
!   st1 = SYMBOL_SOURCE_NAME (*s1);
!   st2 = SYMBOL_SOURCE_NAME (*s2);
  
  
    if ((st1[0] - st2[0]) || !st1[0])
--- 245,252 ----
  
    s1 = (struct partial_symbol **) s1p;
    s2 = (struct partial_symbol **) s2p;
!   st1 = SYMBOL_NAME (*s1);
!   st2 = SYMBOL_NAME (*s2);
  
  
    if ((st1[0] - st2[0]) || !st1[0])
Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.22
diff -c -3 -p -r1.22 symtab.c
*** symtab.c	2000/11/10 23:02:56	1.22
--- symtab.c	2000/11/16 17:06:37
*************** lookup_symbol (const char *name, const s
*** 563,569 ****
  {
    char *modified_name = NULL;
    char *modified_name2 = NULL;
-   int needtofreename = 0;
    struct symbol *returnval;
  
    if (case_sensitivity == case_sensitive_off)
--- 563,568 ----
*************** lookup_symbol (const char *name, const s
*** 581,603 ****
    else 
        modified_name = (char *) name;
  
-   /* If we are using C++ language, demangle the name before doing a lookup, so
-      we can always binary search. */
-   if (current_language->la_language == language_cplus)
-     {
-       modified_name2 = cplus_demangle (modified_name, DMGL_ANSI | DMGL_PARAMS);
-       if (modified_name2)
- 	{
- 	  modified_name = modified_name2;
- 	  needtofreename = 1;
- 	}
-     }
- 
    returnval = lookup_symbol_aux (modified_name, block, namespace,
  				 is_a_field_of_this, symtab);
-   if (needtofreename)
-     free (modified_name2);
- 
    return returnval;	 
  }
  
--- 580,587 ----
*************** lookup_symbol_aux (const char *name, con
*** 772,778 ****
  	    {
  	      /* This is a mangled variable, look it up by its
  	         mangled name.  */
! 	      return lookup_symbol (SYMBOL_NAME (msymbol), block,
  				    namespace, is_a_field_of_this, symtab);
  	    }
  	  /* There are no debug symbols for this file, or we are looking
--- 756,762 ----
  	    {
  	      /* This is a mangled variable, look it up by its
  	         mangled name.  */
! 	      return lookup_symbol_aux (SYMBOL_NAME (msymbol), block,
  				    namespace, is_a_field_of_this, symtab);
  	    }
  	  /* There are no debug symbols for this file, or we are looking
*************** lookup_symbol_aux (const char *name, con
*** 950,956 ****
  		   && MSYMBOL_TYPE (msymbol) != mst_file_text
  		   && !STREQ (name, SYMBOL_NAME (msymbol)))
  	    {
! 	      return lookup_symbol (SYMBOL_NAME (msymbol), block,
  				    namespace, is_a_field_of_this, symtab);
  	    }
  	}
--- 934,940 ----
  		   && MSYMBOL_TYPE (msymbol) != mst_file_text
  		   && !STREQ (name, SYMBOL_NAME (msymbol)))
  	    {
! 	      return lookup_symbol_aux (SYMBOL_NAME (msymbol), block,
  				    namespace, is_a_field_of_this, symtab);
  	    }
  	}
*************** lookup_symbol_aux (const char *name, con
*** 964,971 ****
  }
  								
  /* Look, in partial_symtab PST, for symbol NAME.  Check the global
!    symbols if GLOBAL, the static symbols if not */
  
  static struct partial_symbol *
  lookup_partial_symbol (struct partial_symtab *pst, const char *name, int global,
  		       namespace_enum namespace)
--- 948,960 ----
  }
  								
  /* Look, in partial_symtab PST, for symbol NAME.  Check the global
!    symbols if GLOBAL, the static symbols if not. 
  
+    Be aware that minimal symbols have no demangled names. So we need to lookup
+    by mangled name. However, this also means we can always binary search them, 
+    since they are a sorted list. If you change the way partial symbols work, 
+    you'll need to change this routine.  */
+ 
  static struct partial_symbol *
  lookup_partial_symbol (struct partial_symtab *pst, const char *name, int global,
  		       namespace_enum namespace)
*************** lookup_partial_symbol (struct partial_sy
*** 1001,1011 ****
  	  if (!(center < top))
  	    abort ();
  	  if (!do_linear_search
! 	      && (SYMBOL_LANGUAGE (*center) == language_java))
  	    {
  	      do_linear_search = 1;
! 	    }
! 	  if (STRCMP (SYMBOL_SOURCE_NAME (*center), name) >= 0)
  	    {
  	      top = center;
  	    }
--- 990,1002 ----
  	  if (!(center < top))
  	    abort ();
  	  if (!do_linear_search
! 	      && (SYMBOL_LANGUAGE (*center) == language_cplus
! 		  || SYMBOL_LANGUAGE (*center) == language_java
! 		  ))
  	    {
  	      do_linear_search = 1;
! 	    }	  
!   	  if (STRCMP (SYMBOL_NAME (*center), name) >= 0)
  	    {
  	      top = center;
  	    }
*************** lookup_block_symbol (register const stru
*** 1226,1244 ****
  	    }
  	  inc = (inc >> 1) + bot;
  	  sym = BLOCK_SYM (block, inc);
! 	  if (!do_linear_search && (SYMBOL_LANGUAGE (sym) == language_java))
  	    {
  	      do_linear_search = 1;
  	    }
! 	  if (SYMBOL_SOURCE_NAME (sym)[0] < name[0])
  	    {
  	      bot = inc;
  	    }
! 	  else if (SYMBOL_SOURCE_NAME (sym)[0] > name[0])
  	    {
  	      top = inc;
  	    }
! 	  else if (STRCMP (SYMBOL_SOURCE_NAME (sym), name) < 0)
  	    {
  	      bot = inc;
  	    }
--- 1217,1235 ----
  	    }
  	  inc = (inc >> 1) + bot;
  	  sym = BLOCK_SYM (block, inc);
! 	  if (!do_linear_search && ((SYMBOL_LANGUAGE (sym) == language_java) || SYMBOL_LANGUAGE (sym) == language_cplus))
  	    {
  	      do_linear_search = 1;
  	    }
! 	  if (SYMBOL_NAME (sym)[0] < name[0])
  	    {
  	      bot = inc;
  	    }
! 	  else if (SYMBOL_NAME (sym)[0] > name[0])
  	    {
  	      top = inc;
  	    }
! 	  else if (STRCMP (SYMBOL_NAME (sym), name) < 0)
  	    {
  	      bot = inc;
  	    }

Re: [RFA]: Fix partial symbol lookups

[Daniel Berlin]

"Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de> writes:

> > No, I'll clean it up if you like. Assuming you don't want me to just
> > revert all the 10-12 changes and be done with it.
> 
> This decision has to be made by the symtab maintainers of course.

Sure, but i'd appreciate a friendly opinion as to whether these
patches have any hope or not.

> 
> > > No, it points out another problem with `maint check'. Have you ever tried it
> > > with your patches ?
> > 
> > Yes, I have.
> > (gdb) maintenance check-symtabs 
> > During symbol reading, type qualifier 'const' ignored.
> > During symbol reading, unsupported stack op: 'DW_OP_deref_size'.
> > During symbol reading, type qualifier 'volatile' ignored.
> > (gdb)
> 
> Well, with gcc-2.95.2 -ggdb on a linux x86 box I get
> 
> (gdb) maint check
> During symbol reading, type qualifier 'const' ignored.
> During symbol reading, type qualifier 'volatile' ignored.
> During symbol reading, type qualifier 'const' ignored.
> Global symbol `__24Contains_static_instanceii' only found in misc.cc psymtab
> Global symbol `__31Contains_nested_static_instanceii' only found in misc.cc psym
> tab
> Global symbol `__3Bariii' only found in misc.cc psymtab
> Global symbol `__3Fooii' only found in misc.cc psymtab
> Global symbol `__5Base1i' only found in misc.cc psymtab
> Global symbol `__Q231Contains_nested_static_instance6Nestedi' only found in misc
> .cc psymtab
> Global symbol `__opi__3Foo' only found in misc.cc psymtab
> Global symbol `foo__C22const_vol_method_classRi' only found in misc.cc psymtab
> Global symbol `times__3Fooi' only found in misc.cc psymtab
> 
> which is not surprising, because maintenance_check_symtabs calls
> lookup_block_symbol with the mangled symbol name.
> Perhaps you have applied more patches to your source tree...

Hmmmm.
Weird.

I am using  a different gcc, but this shouldn't account for it.

--Dan

Re: [RFA]: Fix partial symbol lookups

[Daniel Berlin]

"Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de> writes:

> > > The previous version of lookup_partial_symbol (before your changes) would
> > > have found both mangled and demangled names.
> > 
> > Now this I take issue with.
> > How could it possibly find demangled names, if it doesn't have access
> > to them?
> > lookup_partial_symbol didn't find demangled names before my patch on
> > 10-12. It doesn't have the code to do so, as you pointed out yourself
> > (because the SYMBOL_MATCHES_NAME is no better than the strcmp, since
> > we have no access to demangled names), unless the symbol name was the
> > demangled name, rather than the mangled name, which doesn't occur.
> 
> Not true.
> There were no demangled names in partial symbols from most symbol readers,
> _except_ for the HP reader, which we are currently discussing, and which
> I discovered rather late in the day as well.
> Before your change, lookup_partial_symbol fell back to a linear search
> if it didn't find the symbol and had the chance to find the demangled symbol
> via SYMBOL_MATCHES_NAME during the linear search.

Peter, you are missing an important point.

*I* added that SYMBOL_MATCHES_NAME. Not HP. As the comment shows
right above it.

In the GDB-5.0 source, it's    


   while (STREQ (SYMBOL_NAME (*top), name))
        {
          if (SYMBOL_NAMESPACE (*top) == namespace)
            {
              return (*top);
            }
          top++;
        }



So we couldn't have possibly been finding demangled names until I
added that, and since the HP code is older than the change to use
SYMBOL_MATCHES_NAME, they couldn't have had demangled names working in
partial symbol lookups.
--Dan

Re: [RFA]: Fix partial symbol lookups

[Daniel Berlin]

Daniel Berlin <dberlin@redhat.com> writes:

> "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de> writes:
> 
> > > > The previous version of lookup_partial_symbol (before your changes) would
> > > > have found both mangled and demangled names.
> > > 
> > > Now this I take issue with.
> > > How could it possibly find demangled names, if it doesn't have access
> > > to them?
> > > lookup_partial_symbol didn't find demangled names before my patch on
> > > 10-12. It doesn't have the code to do so, as you pointed out yourself
> > > (because the SYMBOL_MATCHES_NAME is no better than the strcmp, since
> > > we have no access to demangled names), unless the symbol name was the
> > > demangled name, rather than the mangled name, which doesn't occur.
> > 
> > Not true.
> > There were no demangled names in partial symbols from most symbol readers,
> > _except_ for the HP reader, which we are currently discussing, and which
> > I discovered rather late in the day as well.
> > Before your change, lookup_partial_symbol fell back to a linear search
> > if it didn't find the symbol and had the chance to find the demangled symbol
> > via SYMBOL_MATCHES_NAME during the linear search.
> 
> Peter, you are missing an important point.
> 
> *I* added that SYMBOL_MATCHES_NAME. Not HP. As the comment shows
> right above it.
> 
> In the GDB-5.0 source, it's    
> 
>    while (STREQ (SYMBOL_NAME (*top), name))
>         {
>           if (SYMBOL_NAMESPACE (*top) == namespace)
>             {
>               return (*top);
>             }
>           top++;
>         }
> 

Of course, I copied the wrong piece of code.
Sigh.

--Dan

Re: [RFA]: Fix partial symbol lookups

[Christopher Faylor]

I wanted to let everyone know that Jim Blandy is aware of this thread
and wants to help move things along but his internet connection is down
currently and, additionally, he is in the middle of an important
project.

(Of course saying that he is in the middle of an important project and
his internet connection is down may be redundant.  Doesn't it always
work that way?)

So, with luck, he'll be weighing in with an opinion on Monday.

FYI,
cgf
From msnyder@redhat.com Thu Nov 16 11:35:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: Orjan Friberg <orjan.friberg@axis.com>
Cc: Fernando Nasser <fnasser@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: Relying on tm-target.h macros in target-tdep.c
Date: Thu, 16 Nov 2000 11:35:00 -0000
Message-id: <3A1436FD.581FDFDB@redhat.com>
References: <3A13C9E5.D5465E2C@axis.com> <3A13E1F7.8CCB0A4C@cygnus.com> <3A13FD96.639B2F6@axis.com>
X-SW-Source: 2000-11/msg00213.html
Content-length: 3519

Orjan Friberg wrote:
> 
> Fernando Nasser wrote:
> >
> > First of all, your tm-???.h file is already included.  Look in your build
> > directory and you'll find a link "tm.h" that points to it (if not your
> > configuration is broken).  tm.h goes in defs.h, and the latter is included
> > everywhere.  (BTW, this is explained in the gdb internals manual --
> > gdb/doc/gdbint.texinfo).
> >
> 
> Thanks, I knew about the tm.h-link, but I had missed the connection with
> defs.h.
> 
> > You haven't told us why you need these things in your gdbarch_init,
> > and that is your real problem.  You should not need any of this in there.
> >
> > Give us an example of the use of one of these things in there.
> > I bet you should be using something from bfd.
> >
> 
> Ok, the problem is that I'm adding support for two versions in the same
> chip series, which have different sizes (16 vs 32 bits) for one of the
> registers. The new chip is backwards compatible, which means I cannot
> know for sure which chip version the target actually is until I read the
> version register, in case the binary was compiled for the older chip.

This is not a unique situation.  Other targets with multiple generations
face the same problem.  Go with what the binary says it is, and then 
switch on the fly later if needed.  You cannot assume that you can
read register values from within gdbarch_init.  You might not be 
connected to any target at that time.  Registers might not be available.


> This affects register_byte, register_raw_size, register_virtual_size,
> which are implemented via function pointers.

You should have a different version of each of those functions for
each chip variation.  Unles you want to try and be clever  by having
a single function that detects on the fly what the chip is, but I
do not recommend it if you are doing this for the first time.

You must create a separate gdbarch struct for each chip variation.
The 16-bit gdbarch will point to the 16-bit functions, and so forth.

At runtime (as opposed to initialization time), gdb must decide
which gdbarch to use.

> They make use of the
> information in opcodes/cris-opc.c to get the register sizes by looking
> at the chip version which I've added to my tdep struct (Yes; I hope to
> have the chip version sorted out by the time these functions are called
> -- otherwise I have to rely on the uneducated guess I make in
> gdbarch_init).

Don't do it this way.  You are trying to be too clever.
Implement a separate version of each function for each chip, 
and point to them with separate gdbarch objects.  Let the user
set the chip version by hand, if necessary, until you get the
auto-detection issues straightened out.

> register_bytes OTOH, is an int, which means I cannot
> "postpone" that decision.

Not in your current design -- which is why you shouldn't use it.
Start simple, become more complex as time and foundation permit.
 
> Basically, there is information about registers vs chip versions in
> opcodes/cris-opc.c that I'd like to use (via register_size), instead of
> duplicating that information in gdbarch_init. It's not that big of a
> deal though.
> 
> (When/how I will be able to decide on the actual chip version is another
> story. Right now I'm just adding the framework for supporting both
> chips.)

My impression is that you're trying to do it with a single
gdbarch object.  That's not the idea.

> 
> --
> Orjan Friberg              E-mail: orjan.friberg@axis.com
> Axis Communications AB     Phone:  +46 46 272 17 68
From cgf@redhat.com Thu Nov 16 12:18:00 2000
From: Christopher Faylor <cgf@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [RFA]: Fix partial symbol lookups
Date: Thu, 16 Nov 2000 12:18:00 -0000
Message-id: <20001116151800.A22508@redhat.com>
References: <200011161222.NAA05985@reisser.regent.e-technik.tu-muenchen.de> <m38zqj3mcb.fsf@dan2.cygnus.com> <20001116140122.A21436@redhat.com>
X-SW-Source: 2000-11/msg00214.html
Content-length: 646

On Thu, Nov 16, 2000 at 02:01:22PM -0500, Christopher Faylor wrote:
>I wanted to let everyone know that Jim Blandy is aware of this thread
>and wants to help move things along but his internet connection is down
>currently and, additionally, he is in the middle of an important
>project.
>
>(Of course saying that he is in the middle of an important project and
>his internet connection is down may be redundant.  Doesn't it always
>work that way?)
>
>So, with luck, he'll be weighing in with an opinion on Monday.

I probably should note, in case it isn't obvious, that Jim is the
primary maintainer for the patches that Dan is submitting.

cgf
From Peter.Schauer@regent.e-technik.tu-muenchen.de Thu Nov 16 12:39:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: dberlin@redhat.com (Daniel Berlin)
Cc: msnyder@cygnus.com, jimb@cygnus.com, gdb-patches@sources.redhat.com, ezannoni@cygnus.com
Subject: Re: [RFA]: Fix partial symbol lookups
Date: Thu, 16 Nov 2000 12:39:00 -0000
Message-id: <200011162039.VAA06942@reisser.regent.e-technik.tu-muenchen.de>
References: <m3lmuj26vd.fsf@dan2.cygnus.com>
X-SW-Source: 2000-11/msg00215.html
Content-length: 1706

> > Not true.
> > There were no demangled names in partial symbols from most symbol readers,
> > _except_ for the HP reader, which we are currently discussing, and which
> > I discovered rather late in the day as well.
> > Before your change, lookup_partial_symbol fell back to a linear search
> > if it didn't find the symbol and had the chance to find the demangled symbol
> > via SYMBOL_MATCHES_NAME during the linear search.
> 
> Peter, you are missing an important point.
> 
> *I* added that SYMBOL_MATCHES_NAME. Not HP. As the comment shows
> right above it.
	.
	.
> So we couldn't have possibly been finding demangled names until I
> added that, and since the HP code is older than the change to use
> SYMBOL_MATCHES_NAME, they couldn't have had demangled names working in
> partial symbol lookups.

Sorry, but wrong again.
Since gdb-4.8 we have the following in lookup_partial_symbol:

          if (!do_linear_search && SYMBOL_LANGUAGE (center) == language_cplus)
            {
              do_linear_search = 1;
            }

So lookup_partial_symbol falls back to a linear search if either the mangled
or demangled partial symbol is not found.
And the linear search does this:

              if (SYMBOL_MATCHES_NAME (psym, name))
                {
                  return (psym);
                }

which will match either the mangled or the demangled partial symbol name.

It might have been my fault not to remove all this in gdb-4.14, as the symbol
readers back then wouldn't have needed it.
But now with the HP symtab reader and the HPUXHPPA defines in lookup_symbol
it might be needed again.
At least _I_ don't dare to remove it.

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From geoffk@thief.cygnus.com Thu Nov 16 13:27:00 2000
From: Geoffrey Keating <geoffk@thief.cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: sim patch for new cpplib
Date: Thu, 16 Nov 2000 13:27:00 -0000
Message-id: <200011162126.eAGLQWE25953@thief.cygnus.com>
X-SW-Source: 2000-11/msg00216.html
Content-length: 8756

This patch updates the sim for the new, more correct, interpretation
of the ISO C99 standard that GCC currently has.

OK to commit?

-- 
Geoff Keating <geoffk@redhat.com>

===File ~/patches/sim-newcpp.patch==========================
In sim/common:
2000-11-16  Geoffrey Keating  <geoffk@redhat.com>

	* sim-endian.h: Don't have parameters on macro definitions which
	are simply renaming functions, to permit use of XCONCAT2 in both
	the macro name and the arguments in a use of such a definition.

In sim/ppc:
2000-11-16  Geoffrey Keating  <geoffk@redhat.com>

	* sim-endian.h: Don't have parameters on macro definitions which
	are simply renaming functions, to permit use of XCONCAT2 in both
	the macro name and the arguments in a use of such a definition.

Index: sim/common/sim-endian.h
===================================================================
RCS file: /cvs/cvsfiles/devo/sim/common/sim-endian.h,v
retrieving revision 1.12
diff -u -p -r1.12 sim-endian.h
--- sim-endian.h	2000/03/02 09:10:17	1.12
+++ sim-endian.h	2000/11/16 21:22:38
@@ -80,53 +80,53 @@ INLINE_SIM_ENDIAN(unsigned_8) sim_endian
 
 /* SWAP */
 
-#define SWAP_1(X) swap_1(X)
-#define SWAP_2(X) swap_2(X)
-#define SWAP_4(X) swap_4(X)
-#define SWAP_8(X) swap_8(X)
-#define SWAP_16(X) swap_16(X)
+#define SWAP_1 swap_1
+#define SWAP_2 swap_2
+#define SWAP_4 swap_4
+#define SWAP_8 swap_8
+#define SWAP_16 swap_16
 
 
 /* HOST to BE */
 
-#define H2BE_1(X) endian_h2be_1(X)
-#define H2BE_2(X) endian_h2be_2(X)
-#define H2BE_4(X) endian_h2be_4(X)
-#define H2BE_8(X) endian_h2be_8(X)
-#define H2BE_16(X) endian_h2be_16(X)
-#define BE2H_1(X) endian_be2h_1(X)
-#define BE2H_2(X) endian_be2h_2(X)
-#define BE2H_4(X) endian_be2h_4(X)
-#define BE2H_8(X) endian_be2h_8(X)
-#define BE2H_16(X) endian_be2h_16(X)
+#define H2BE_1 endian_h2be_1
+#define H2BE_2 endian_h2be_2
+#define H2BE_4 endian_h2be_4
+#define H2BE_8 endian_h2be_8
+#define H2BE_16 endian_h2be_16
+#define BE2H_1 endian_be2h_1
+#define BE2H_2 endian_be2h_2
+#define BE2H_4 endian_be2h_4
+#define BE2H_8 endian_be2h_8
+#define BE2H_16 endian_be2h_16
 
 
 /* HOST to LE */
 
-#define H2LE_1(X) endian_h2le_1(X)
-#define H2LE_2(X) endian_h2le_2(X)
-#define H2LE_4(X) endian_h2le_4(X)
-#define H2LE_8(X) endian_h2le_8(X)
-#define H2LE_16(X) endian_h2le_16(X)
-#define LE2H_1(X) endian_le2h_1(X)
-#define LE2H_2(X) endian_le2h_2(X)
-#define LE2H_4(X) endian_le2h_4(X)
-#define LE2H_8(X) endian_le2h_8(X)
-#define LE2H_16(X) endian_le2h_16(X)
+#define H2LE_1 endian_h2le_1
+#define H2LE_2 endian_h2le_2
+#define H2LE_4 endian_h2le_4
+#define H2LE_8 endian_h2le_8
+#define H2LE_16 endian_h2le_16
+#define LE2H_1 endian_le2h_1
+#define LE2H_2 endian_le2h_2
+#define LE2H_4 endian_le2h_4
+#define LE2H_8 endian_le2h_8
+#define LE2H_16 endian_le2h_16
 
 
 /* HOST to TARGET */
 
-#define H2T_1(X) endian_h2t_1(X)
-#define H2T_2(X) endian_h2t_2(X)
-#define H2T_4(X) endian_h2t_4(X)
-#define H2T_8(X) endian_h2t_8(X)
-#define H2T_16(X) endian_h2t_16(X)
-#define T2H_1(X) endian_t2h_1(X)
-#define T2H_2(X) endian_t2h_2(X)
-#define T2H_4(X) endian_t2h_4(X)
-#define T2H_8(X) endian_t2h_8(X)
-#define T2H_16(X) endian_t2h_16(X)
+#define H2T_1 endian_h2t_1
+#define H2T_2 endian_h2t_2
+#define H2T_4 endian_h2t_4
+#define H2T_8 endian_h2t_8
+#define H2T_16 endian_h2t_16
+#define T2H_1 endian_t2h_1
+#define T2H_2 endian_t2h_2
+#define T2H_4 endian_t2h_4
+#define T2H_8 endian_t2h_8
+#define T2H_16 endian_t2h_16
 
 
 /* CONVERT IN PLACE
@@ -219,22 +219,22 @@ do { \
    Byte swap a quantity the size of the targets word */
 
 #if (WITH_TARGET_WORD_BITSIZE == 64)
-#define H2T_word(X) H2T_8(X)
-#define T2H_word(X) T2H_8(X)
-#define H2BE_word(X) H2BE_8(X)
-#define BE2H_word(X) BE2H_8(X)
-#define H2LE_word(X) H2LE_8(X)
-#define LE2H_word(X) LE2H_8(X)
-#define SWAP_word(X) SWAP_8(X)
+#define H2T_word H2T_8
+#define T2H_word T2H_8
+#define H2BE_word H2BE_8
+#define BE2H_word BE2H_8
+#define H2LE_word H2LE_8
+#define LE2H_word LE2H_8
+#define SWAP_word SWAP_8
 #endif
 #if (WITH_TARGET_WORD_BITSIZE == 32)
-#define H2T_word(X) H2T_4(X)
-#define T2H_word(X) T2H_4(X)
-#define H2BE_word(X) H2BE_4(X)
-#define BE2H_word(X) BE2H_4(X)
-#define H2LE_word(X) H2LE_4(X)
-#define LE2H_word(X) LE2H_4(X)
-#define SWAP_word(X) SWAP_4(X)
+#define H2T_word H2T_4
+#define T2H_word T2H_4
+#define H2BE_word H2BE_4
+#define BE2H_word BE2H_4
+#define H2LE_word H2LE_4
+#define LE2H_word LE2H_4
+#define SWAP_word SWAP_4
 #endif
 
 
@@ -243,13 +243,13 @@ do { \
 
    Byte swap a quantity the size of the targets IEEE 1275 memory cell */
 
-#define H2T_cell(X) H2T_4(X)
-#define T2H_cell(X) T2H_4(X)
-#define H2BE_cell(X) H2BE_4(X)
-#define BE2H_cell(X) BE2H_4(X)
-#define H2LE_cell(X) H2LE_4(X)
-#define LE2H_cell(X) LE2H_4(X)
-#define SWAP_cell(X) SWAP_4(X)
+#define H2T_cell H2T_4
+#define T2H_cell T2H_4
+#define H2BE_cell H2BE_4
+#define BE2H_cell BE2H_4
+#define H2LE_cell H2LE_4
+#define LE2H_cell LE2H_4
+#define SWAP_cell SWAP_4
 
 
 
Index: sim/ppc/sim-endian.h
===================================================================
RCS file: /cvs/cvsfiles/devo/sim/ppc/sim-endian.h,v
retrieving revision 1.9
diff -u -p -r1.9 sim-endian.h
--- sim-endian.h	2000/03/02 09:24:23	1.9
+++ sim-endian.h	2000/11/16 21:22:38
@@ -246,46 +246,46 @@ INLINE_SIM_ENDIAN(unsigned_8) endian_le2
 
 /* SWAP */
 
-#define SWAP_1(X) swap_1(X)
-#define SWAP_2(X) swap_2(X)
-#define SWAP_4(X) swap_4(X)
-#define SWAP_8(X) swap_8(X)
+#define SWAP_1 swap_1
+#define SWAP_2 swap_2
+#define SWAP_4 swap_4
+#define SWAP_8 swap_8
 
 
 /* HOST to BE */
 
-#define H2BE_1(X) endian_h2be_1(X)
-#define H2BE_2(X) endian_h2be_2(X)
-#define H2BE_4(X) endian_h2be_4(X)
-#define H2BE_8(X) endian_h2be_8(X)
-#define BE2H_1(X) endian_be2h_1(X)
-#define BE2H_2(X) endian_be2h_2(X)
-#define BE2H_4(X) endian_be2h_4(X)
-#define BE2H_8(X) endian_be2h_8(X)
+#define H2BE_1 endian_h2be_1
+#define H2BE_2 endian_h2be_2
+#define H2BE_4 endian_h2be_4
+#define H2BE_8 endian_h2be_8
+#define BE2H_1 endian_be2h_1
+#define BE2H_2 endian_be2h_2
+#define BE2H_4 endian_be2h_4
+#define BE2H_8 endian_be2h_8
 
 
 /* HOST to LE */
 
-#define H2LE_1(X) endian_h2le_1(X)
-#define H2LE_2(X) endian_h2le_2(X)
-#define H2LE_4(X) endian_h2le_4(X)
-#define H2LE_8(X) endian_h2le_8(X)
-#define LE2H_1(X) endian_le2h_1(X)
-#define LE2H_2(X) endian_le2h_2(X)
-#define LE2H_4(X) endian_le2h_4(X)
-#define LE2H_8(X) endian_le2h_8(X)
+#define H2LE_1 endian_h2le_1
+#define H2LE_2 endian_h2le_2
+#define H2LE_4 endian_h2le_4
+#define H2LE_8 endian_h2le_8
+#define LE2H_1 endian_le2h_1
+#define LE2H_2 endian_le2h_2
+#define LE2H_4 endian_le2h_4
+#define LE2H_8 endian_le2h_8
 
 
 /* HOST to TARGET */
 
-#define H2T_1(X) endian_h2t_1(X)
-#define H2T_2(X) endian_h2t_2(X)
-#define H2T_4(X) endian_h2t_4(X)
-#define H2T_8(X) endian_h2t_8(X)
-#define T2H_1(X) endian_t2h_1(X)
-#define T2H_2(X) endian_t2h_2(X)
-#define T2H_4(X) endian_t2h_4(X)
-#define T2H_8(X) endian_t2h_8(X)
+#define H2T_1 endian_h2t_1
+#define H2T_2 endian_h2t_2
+#define H2T_4 endian_h2t_4
+#define H2T_8 endian_h2t_8
+#define T2H_1 endian_t2h_1
+#define T2H_2 endian_t2h_2
+#define T2H_4 endian_t2h_4
+#define T2H_8 endian_t2h_8
 
 
 /* CONVERT IN PLACE
@@ -370,22 +370,22 @@ do { \
    Byte swap a quantity the size of the targets word */
 
 #if (WITH_TARGET_WORD_BITSIZE == 64)
-#define H2T_word(X) H2T_8(X)
-#define T2H_word(X) T2H_8(X)
-#define H2BE_word(X) H2BE_8(X)
-#define BE2H_word(X) BE2H_8(X)
-#define H2LE_word(X) H2LE_8(X)
-#define LE2H_word(X) LE2H_8(X)
-#define SWAP_word(X) SWAP_8(X)
+#define H2T_word H2T_8
+#define T2H_word T2H_8
+#define H2BE_word H2BE_8
+#define BE2H_word BE2H_8
+#define H2LE_word H2LE_8
+#define LE2H_word LE2H_8
+#define SWAP_word SWAP_8
 #endif
 #if (WITH_TARGET_WORD_BITSIZE == 32)
-#define H2T_word(X) H2T_4(X)
-#define T2H_word(X) T2H_4(X)
-#define H2BE_word(X) H2BE_4(X)
-#define BE2H_word(X) BE2H_4(X)
-#define H2LE_word(X) H2LE_4(X)
-#define LE2H_word(X) LE2H_4(X)
-#define SWAP_word(X) SWAP_4(X)
+#define H2T_word H2T_4
+#define T2H_word T2H_4
+#define H2BE_word H2BE_4
+#define BE2H_word BE2H_4
+#define H2LE_word H2LE_4
+#define LE2H_word LE2H_4
+#define SWAP_word SWAP_4
 #endif
 
 
@@ -393,13 +393,13 @@ do { \
 
    Byte swap a quantity the size of the targets IEEE 1275 memory cell */
 
-#define H2T_cell(X) H2T_4(X)
-#define T2H_cell(X) T2H_4(X)
-#define H2BE_cell(X) H2BE_4(X)
-#define BE2H_cell(X) BE2H_4(X)
-#define H2LE_cell(X) H2LE_4(X)
-#define LE2H_cell(X) LE2H_4(X)
-#define SWAP_cell(X) SWAP_4(X)
+#define H2T_cell H2T_4
+#define T2H_cell T2H_4
+#define H2BE_cell H2BE_4
+#define BE2H_cell BE2H_4
+#define H2LE_cell H2LE_4
+#define LE2H_cell LE2H_4
+#define SWAP_cell SWAP_4
 
 
 #if (SIM_ENDIAN_INLINE & INCLUDE_MODULE)
============================================================
From bje@redhat.com Thu Nov 16 15:04:00 2000
From: Ben Elliston <bje@redhat.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: <cgen@sources.redhat.com>, <gdb-patches@sources.redhat.com>
Subject: Re: [RFA] Patch to sim/common/cgen-ops.h
Date: Thu, 16 Nov 2000 15:04:00 -0000
Message-id: <Pine.LNX.4.30.0011171001420.11755-100000@moshpit.cygnus.com>
References: <20001116074145.B6787@redhat.com>
X-SW-Source: 2000-11/msg00217.html
Content-length: 819

fche wrote:

   :      * the way to handle out-of-range arguments to the SUBWORD
   :        functions.  Perhaps it's okay to use assert(), since we're
   :        wasting a few cycles already by doing the test.

   Sure.

I'll make that change, then.

   :      * whether it makes sense to join two SFs into a DF.

   i.e., make a double out of two floats?  I don't think so. Maybe you
   mean to build a DF out of two SI's -- go through a DI first then.

No, I want to join two SFs together to form a DF -- one architecture that I
am thinking of allows you to store pairs of single precision fp registers in
one of its double precision fp registers.  If you can think of a simpler way
(perhaps using bitwise operators?), then we can eliminate the need for this.
I just thought that using (join ..) was clearer.

Ben

Re: [RFA]: Fix partial symbol lookups

[Michael Snyder]

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.

> 
> 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?
If so, then this should be a big improvement.

> Since we
> only have a sorted list of mangled names in the global list, there is
> no reason to linear search it, ever.
> Statics still aren't sorted, so we linear search those.

Hmmm -- so why not sort the statics?
From Peter.Schauer@regent.e-technik.tu-muenchen.de Wed Nov 15 10:17:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: msnyder@redhat.com (Michael Snyder)
Cc: dberlin@redhat.com, jimb@cygnus.com, gdb-patches@sources.redhat.com, ezannoni@cygnus.com
Subject: Re: [RFA]: Fix partial symbol lookups
Date: Wed, 15 Nov 2000 10:17:00 -0000
Message-id: <200011151817.TAA05077@reisser.regent.e-technik.tu-muenchen.de>
References: <3A12C01A.659A@redhat.com>
X-SW-Source: 2000-11/msg00173.html
Content-length: 1616

> 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.

They were not true from 1994 - Dec 1998 and I should be blamed that I
didn't remove the code and comment when I removed the demangling of 
partial symbols back in 1994, my sincere apologies.

> > 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?
> If so, then this should be a big improvement.

I just double checked once again. 
add_psymbol_to_list (which is used by most symbol readers) calls 
SYMBOL_INIT_LANGUAGE_SPECIFIC (&psymbol, language), which sets the demangled
name to NULL.

But wait, the HP patches reintroduced the demangling of partial symbols
for their symbol reader (look for add_psymbol_with_dem_name_to_list).

This is really bad, as GDB now has to cope with the presence and non-presence
of demangling in partial symbols. I'd be very reluctant to reintroduce
the demangling of partial symbols for all other symbol readers, instead
someone should fix the HP reader to not need the demangling of partial
symbols.

I am now afraid that we have to back out all 2000-10-12 Dan Berlin changes,
to get a reliably working (and perhaps sometimes slower) GDB again.

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From dberlin@redhat.com Wed Nov 15 10:43:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Michael Snyder <msnyder@redhat.com>
Cc: Jim Blandy <jimb@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA]: Fix partial symbol lookups
Date: Wed, 15 Nov 2000 10:43:00 -0000
Message-id: <m3g0ktkrjh.fsf@dan2.cygnus.com>
References: <m3vgtqv60a.fsf@dan2.cygnus.com> <npbsvhzxm9.fsf@zwingli.cygnus.com> <m3hf59izpl.fsf@dan2.cygnus.com> <3A12C01A.659A@redhat.com>
X-SW-Source: 2000-11/msg00174.html
Content-length: 1753

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. 
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.

Sat Oct  8 04:27:21 1994  Peter Schauer
(pes@regent.e-technik.tu-muenchen.de)

        Speed up GDB startup time by not demangling partial symbols.
        * symfile.h (ADD_PSYMBOL_VT_TO_LIST),
        symfile.c (add_psymbol_to_list, add_psymbol_addr_to_list):
        No longer demangle partial symbols.
        * symtab.c (lookup_symbol, list_symbols): Handle mangled
        variables, e.g. C++ static members, via the minimal symbols.
Since this happened, the only calls to SYMBOL_INIT_DEMANGLED_NAME is in
the symreaders, and only occur on full symbols.

> If so, then this should be a big improvement.
Yup.

> 
> > Since we
> > only have a sorted list of mangled names in the global list, there is
> > 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.
--Dan

Re: [RFA]: Fix partial symbol lookups

[Michael Snyder]

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;