From: Iain Buclaw <ibuclaw@gdcproject.org>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 5/5] Fix for D demangling in GDB
Date: Fri, 10 Jan 2014 23:09:00 -0000 [thread overview]
Message-ID: <CABOHX+dES06wzx2KCjm_Oyc4ftUDy=DOLcLeVse_FEuHDhUbhg@mail.gmail.com> (raw)
In-Reply-To: <87vbxr4jmk.fsf@fleche.redhat.com>
On 10 January 2014 21:22, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Iain" == Iain Buclaw <ibuclaw@gdcproject.org> writes:
>
> Tom> It's also worth noting that with a bit more work you could push the D
> Tom> demangler into libiberty (see ada_demangle there) and then get
> Tom> demangling from "nm" and the other binutils.
>
> Iain> That sounds like a good plan. I'll keep a note to get round to do that.
>
> Just FYI - I'm not sure if you know this or not, but libiberty is
> canonically maintained in the GCC tree, so if you do this, it has to be
> submitted there first. Then it will be merged (either by me, or by
> whoever else seems to be doing (semi-)automated merges) into
> binutils-gdb.git. So, it's a little bit of a pain.
>
Incidentally, I have a assignment form for GCC that has been sitting
in my inbox waiting to be signed and sent off. This will probably
give me an excuse to get round to do that.
I've ported this demangler over to libiberty, changing obstack ->
string where appropriate. Whilst happy at the result, I think I'll
wait until I've finished off demangling D templates. Which is the only
part of demangling where things get a bit hairy (and also why I chose
to move demangling in a separate file).
> Iain> This was copied from cp-demangle.exp. I believe it is written that
> Iain> way so that all demangle tests are ran, rather than stopping at the
> Iain> first error?
>
> The C++ one only works proc-by-proc. If a test fails with a Tcl error
> -- which btw isn't the same as just an ordinary failure, those don't
> cause particular problems -- then it will run the subsequent procs.
> Your test file only has a single proc; and anyway I'm guessing that code
> in the C++ test is not useful anyway. I think dropping it from your
> patch is safe.
>
OK, thanks for the explaination.
Regards
Iain.
prev parent reply other threads:[~2014-01-10 23:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-09 13:13 Iain Buclaw
2014-01-09 21:54 ` Tom Tromey
2014-01-10 13:24 ` Iain Buclaw
2014-01-10 14:51 ` Iain Buclaw
2014-01-10 21:43 ` Tom Tromey
2014-01-11 20:08 ` Iain Buclaw
2014-01-10 15:05 ` Iain Buclaw
2014-01-10 21:45 ` Tom Tromey
2014-01-11 20:18 ` Iain Buclaw
2014-01-13 20:04 ` Tom Tromey
2014-01-18 18:24 ` Iain Buclaw
2014-01-10 21:22 ` Tom Tromey
2014-01-10 23:09 ` Iain Buclaw [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABOHX+dES06wzx2KCjm_Oyc4ftUDy=DOLcLeVse_FEuHDhUbhg@mail.gmail.com' \
--to=ibuclaw@gdcproject.org \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox