Re: [PATCH 5/5] Fix for D demangling in GDB

[Iain Buclaw <ibuclaw at gdcproject dot org>]

On 9 January 2014 21:54, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Iain" == Iain Buclaw <ibuclaw@gdcproject.org> writes:
>
> Iain>         * d-lang.h (d_parse_symbol): Add declaration.
> Iain>         * d-lang.c (extract_identifiers)
> Iain>         (extract_type_info): Remove functions.
> Iain>         (d_demangle): Use d_parse_symbol implemented in d-support.c to
> Iain>         demangle D symbols.
> Iain>         * d-support.c: New file.
>
> The usual approach in cases like this is to do a "pure move" patch to
> move the functions to another file, followed by a second patch to
> implement the fixes.
>

OK, I'll split it into two separate patches.

> It's also worth noting that with a bit more work you could push the D
> demangler into libiberty (see ada_demangle there) and then get
> demangling from "nm" and the other binutils.
>

That sounds like a good plan.  I'll keep a note to get round to do that.


> Iain> +proc catch_demangling_errors {command} {
> Iain> +    if {[catch $command result]} {
> Iain> + puts "ERROR: demangle.exp: while running $command: $result"
> Iain> +    }
> Iain> +}
>
> Iain> +    # Using catch_demangling_errors this way ensures that, if one of
> Iain> +    # the functions raises a Tcl error, then it'll get reported, and
> Iain> +    # the rest of the functions will still run.
> Iain> +    catch_demangling_errors test_d_demangling
>
> I don't think this stuff is needed.  Usually we just let Tcl errors keep
> going, since ordinarily they represent bugs in the test case.  Is there
> a particular failure you were seeing?
>

This was copied from cp-demangle.exp.  I believe it is written that
way so that all demangle tests are ran, rather than stopping at the
first error?