PATCH: Fix PR gdb/592, memory leaks in calls

[Stephane Carrez]

Hi Daniel,

Daniel Jacobowitz wrote:

> This was interesting.  Things I learned while doing this:
>   - our logic for making these symbol overload lists is very bad, and in
>    fact could not work properly.  Fixed.
>   - Doing so is very slow - not fixed.
>   - Doing so is _ridiculously_ slow - because we kept demangling things. 
>    Fixed.
>   - We leaked memory - fixed.
>   - libiberty's cplus_dem leaks memory - not fixed, but avoided and
>    reported.
>   - Our testsuite doesn't cover this function properly - not fixed, but
>    I'll try to get to this.
>   - It hasn't worked with GCC in quite some time, because DMGL_ARM has no
>    business being specified for either v2 (I think) or v3 (definitely)
>    mangled names; so we weren't actually demangling much.
> 
> I've committed this.  There's still a small memory leak but it's on the
> order of 32 bytes instead of 128 MB.
> 
> Stephane, mind verifying that this works correctly for you?
> 
> 

Yes, it really fixed my problem and it's now usable with our big C++ program.
It's slow but acceptable.

Why are we doing some different symbol search in gdb between the 'call' command
and the 'break' command ?

Since 'break' is able to find multiple symbols, I see no reason not to use
its symbol search method (which is lot more faster).

Thanks!!!
	Stephane

-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@nerim.fr                  Stephane.Carrez@solsoft.fr
WWW:    http://stephane.carrez.free.fr     http://www.solsoft.com
         Free the Software!                 Visual Security Policy Management