This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Introduce notion of "search name"


Ping.  I have not yet received a reply after my last message on this
patch, posted Wed, 3 Mar 2004 14:15:50 -0500 (EST).  For reference, I
have appended the initial discussion (minus patch), plus my responses
to David Carlton and Daniel Jacobwitz.  David and Daniel suggested
some minor changes, which you may consider made, but I haven't received 
any definitive word.

Paul Hilfinger

------------------------------------------------------------

Original discussion of 3 March.




The following patch does nothing except to prepare the way for some later
Ada modifications by providing a few "hooks". I've discussed this 
modification earlier on this newsgroup.  At the moment, I've given
the definitions placeholder definitions that simply result in the
current semantics.  I propose to change them when Ada support is turned on.

The idea is to define "search name" as "the name that a language
module uses when searching for this symbol".  As discussed earlier,
the search name would be normally be the natural name, but in the case
of Ada, would just be the linkage name.

The modification to the signature of symbol_natural_name is to allow the
option of delayed (lazy) evaluation of the demangled name, which is
actually the point of introducing search names.

Paul Hilfinger

2004-03-03  Paul N. Hilfinger  <hilfinger@gnat.com>

        * symtab.h (symbol_natural_name): Remove const qualification 
        from argument.
        (SYMBOL_SEARCH_NAME): New definition.
        (SYMBOL_MATCHES_SEARCH_NAME): New definition.
        (SYMBOL_DEMANGLED_SEARCH_NAME): New definition. 

        * dictionary.c (iter_name_first_hashed): Match on SYMBOL_SEARCH_NAME.
        (iter_name_next_hashed): Ditto.
        (iter_name_next_linear): Ditto.
        (insert_symbol_hashed): Hash on SYMBOL_SEARCH_NAME.

        * symtab.c (symbol_natural_name): Remove const qualification from
        argument to allow lazy evaluation of demangled name.
        (lookup_partial_symbol): Assume symbols ordered by search name, using
        SYMBOL_SEARCH_NAME and SYMBOL_MATCHES_SEARCH_NAME.
        
        * symfile.c (compare_psymbols): Order by SYMBOL_SEARCH_NAME.
        
        * minsyms.c (build_minimal_symbol_hash_tables): Use 
        SYMBOL_DEMANGLED_SEARCH_NAME to test for adding to demangled
        hash table.
        
------------------------------------------------------------

Reply to David Carlton of Thu, 4 Mar 2004 03:45:22 -0500 (EST) 


> Personally, I would leave the signature as is and cast away the
> constness when you eventually add this lazy demangling.  My
> justification is that the operation is logically a const operation;
> you're planning to generate some information on the fly, but it
> wouldn't actually change the state of the object.

Sounds fine to me.  I suppose that would be as close to the "mutable" idiom
as one can come in C.

Paul Hilfinger
Hilfinger@gnat.com

------------------------------------------------------------

Reply to Daniel Jacobowitz of Fri, 5 Mar 2004 05:39:25 -0500 (EST)  

Daniel,

> It doesn't address on of the thornier problems I hit when doing the
> same thing, namely that of allocation.  OK, someone uses
> SYMBOL_DEMANGLED_NAME, we lazily allocate a demangled name - where? The
> objfile is not available.  I think there may be no option but to
> pass the objfile to SYMBOL_DEMANGLED_NAME.  What did you do for Ada?

You're right, I did not address this in the patch proper.  I had
prepared a patch in which I used that extra byte in struct symtab to
tag the union and allow an objfile member.  However, I was aware from
correspondence with you that you were working in this area, and that
some of what you proposed to do might eventually allow us to re-do Ada
symbol lookup.  So I decided not to modify the symtab struct for the
moment, and instead submit a patch that would change as little as
possible.  I figured it would be better not to do anything just now
that might interfere with on-going work on the symbol table.

So as an interim measure, I use your suggestion of 21 Jan and first
try to find an objfile via the BFD section.  When that doesn't work, I
simply use a global hashtable to hold the demangled strings.  Yes,
that is a memory leak, but on consideration, I realized that it's only
REALLY a memory leak if (a) I routinely change the entire set of
demangled names numerous times during a single GDB session, or (b)
demangle entirely different, large sets of names each time I reload
the symbol tables.  Yeah, I know, it's not pretty, but again I am hoping
it will ensure that demangled names behave until the next interation of
symtab modifications allow an entirely different strategy.

> You define SYMBOL_DEMANGLED_SEARCH_NAME.  What's it really good for,
> and how does it do any good?  You only use it for the minimal symbol
> hash tables; the fundamental problem with minimal symbols is that we
> don't know their language, so I don't know how you can reliably make a
> language-specific decision like this one.

The relevant code now reads

      if (SYMBOL_DEMANGLED_NAME (msym) != NULL)
        add_minsym_to_demangled_hash_table (msym,
                                            objfile->msymbol_demangled_hash);

Ada does demangle; SYMBOL_DEMANGLED_NAME does have to return a
demangled name, if there is one.  Therefore the test here will
precipitate computing and caching the demangled name prematurely (once
symbol_demangled_name is extended to include the Ada case).  This code
also adds the demangled name to the hash table.  But we never look for
demangled names, so that is a waste.

As to your question about how this can work: Ada doesn't really change
your question.  I could just as well ask "How can
SYMBOL_DEMANGLED_NAME work on minimal symbols, given that it doesn't
know what language to use for demangling?" The answer is that if it
quacks like a duck ... excuse me, I mean if ObjC demangling works,
assume you have an ObjC symbol, if C++ demangling works, then assume
it is a C++ symbol, etc., and hope that the demangling schemes don't
collide.  That's what the code says now.  You'll have to argue the 
sensibility of this strategy with others.

> SYMBOL_DEMANGLED_SEARCH_NAME also codifies more than necessary of the
> difference between the other SYMBOL_*_NAME macros and
> SYMBOL_SEARCH_NAME.  Something that I think may be useful is to use
> just the basename for the search name and then have language-specific
> code to cherry-pick the resulting matches afterwards; one big advantage
> of this is that it lets me sidestep the Java vs. C++ demangling issues.
> I suspect it is possible (for all supported languages) to unambiguously
> and efficiently identify the basename. I need to look at some of the
> other in-use manglings to follow up on that idea though, particularly
> g++ v2 and ObjC.

Yes, I know: you discussed that before and I eagerly await these changes.
For the nonce, I still think I've found a reasonably small hook that 
accomplishes our purposes.

> Oh, and two spaces after a full stop in comments.

Oh, woe: of all your comments, this will be the most difficult to
accommodate.  You see, ACT is full of these confounded Europeans who
insist on single spaces after periods and yell whenever I do things
properly instead.  No doubt they will relent when they hear how this
practice will slow up these patches.  :->).

Paul Hilfinger
Ada Core Technologies, Inc.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]