This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/2] Demangler crash handler
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Gary Benson <gbenson at redhat dot com>
- Cc: Mark Kettenis <mark dot kettenis at xs4all dot nl>, gdb-patches at sourceware dot org
- Date: Tue, 13 May 2014 20:22:25 +0200
- Subject: Re: [PATCH 0/2] Demangler crash handler
- Authentication-results: sourceware.org; auth=none
- References: <20140509100656 dot GA4760 at blade dot nx> <201405091120 dot s49BKO1f010622 at glazunov dot sibelius dot xs4all dot nl> <87fvkhjqvs dot fsf at mid dot deneb dot enyo dot de> <20140513102223 dot GC17805 at blade dot nx>
* Gary Benson:
>> It would be more reliable to run the demangler in a separate
>> process.
>
> Agreed. There are two issues though. First is performance:
> GDB can demangle a lot of symbols--starting GDB on LibreOffice
> demangles more than 369,000 symbols on my machine, and typing
> "b <Tab><Tab>" demangles 2,740,000 more--so the IPC overhead
> has to be seriously low.
Is most of the demangling of the bulk kind? These cases are easy in
the sense that a ping-pong between the two processes is avoidable.
More worrisome would be the occasional demangling as part of other
tasks, where the context switches might become very visible.
>> What's so difficult about fixing the demangler?
>
> It's not so difficult really, but fixes take time to diagnose,
> reproduce, fix, test, review, etc.
I was referring to a more permanent fix, not just patching the bug of
the day as users encounter it.
> During that interval the user cannot use GDB to debug their program.
> This patch is about allowing the user the possibility of getting
> their work done.
I suppose I could run the demangler on all symbols in Fedora and
downstream and see what breaks. Would that help?