[RFC 0/6] Demangle minimal symbol names in worker threads

[Tom Tromey <tom at tromey dot com>]

I've thought for a while that gdb should take advantage of multiple
cores in order to speed up its processing.  This series is some
initial work in that direction.

In particular, this patch arranges to do the demangling for minimal
symbols in worker threads.  I chose this because it seemed relatively
simple to reason about, as the demangler is already mostly thread-safe
(except, as it turns out, the Ada demangler, which is fixed in this
series).  It isn't actually a very important thing to speed up, as
minimal symbol reading is already reasonably speedy; but I thought it
best to start with something straightforward to facilitate flushing
out thread safety bugs.

That said, this does yield a modest speedup on the largest .so on my
system:

A typical pre-patch run looks like:

    /bin/time ./gdb -nx --batch --data-directory ./data-directory/ /usr/lib64/firefox/libxul.so 
    1.22user 0.21system 0:01.46elapsed 98%CPU (0avgtext+0avgdata 188204maxresident)k

And with the patches:

    1.47user 0.39system 0:01.11elapsed 167%CPU (0avgtext+0avgdata 206380maxresident)k

I've only seen %CPU up to 185% or so; but since this is a 4-core
machine I suppose that means there are still gains to be had
somewhere?

This implementation adds a lock to the demangled hash table code.  I
tried a different implementation which did not add locking here.  In
that implementation, minsym names were simply not entered into the
hash table and thus not shared.  However, the lock turned out to be no
slower, and I believe the hash table saves some memory, so I decided
on this approach.

One possible enhancement in this area would be call
build_minimal_symbol_hash_tables in a background thread.  This is
trickier than it sounds, though.  First, it would require more
locking, so that gdb would not attempt to use the minsym hash tables
before they were constructed.  Second, it is possible to introduce
races where the objfile is deleted while the worker thread is still
running.

I have some more ideas for areas in gdb that could benefit from
threads.  I'm happy to discuss if you're interested.

Because threads are tricky, I think this requires some extra scrutiny.
Also I've done various tests using helgrind, which pointed out some of
the things fixed in this series.

You can't readily apply this, because it depends on both the cleanup
removal series and the minsym improvement series.  However it is in my
github repository on the branch "t/parallel-minsyms-mutex".

Tested by the buildbot.

Tom