From: Doug Evans <dje@google.com>
To: Paul Pluzhnikov <ppluzhnikov@google.com>,
Vladimir Prus <vladimir@codesourcery.com>,
tromey@redhat.com, gdb@sources.redhat.com
Subject: Re: Registering pretty-printers
Date: Fri, 12 Jun 2009 16:43:00 -0000 [thread overview]
Message-ID: <e394668d0906120943q5bcc9a92xe94b9ba199d2ffe8@mail.gmail.com> (raw)
In-Reply-To: <20090612005149.GA4987@caradoc.them.org>
On Thu, Jun 11, 2009 at 8:51 PM, Daniel Jacobowitz<drow@false.org> wrote:
> In my opinion, anything that increases the size of the executable is a
> non-starter. I don't think there's any reliable way to create a
> non-allocatable section, and it would have other problems, like
> duplicate elimination.
Reliable in what sense? [I realize the term is pretty unambiguous.
I'm guessing I'm missing something as it doesn't seem to be
excessively hard for many important targets.] Or did you mean
portable?
As for duplicate elimination,
I'm reminded of the new comdat types support in DWARF 4: Type debug
info is put in comdat sections with a signature computed from the
type. The linker removes all duplicates and the result ends up in the
.debug_types section. Employing a similar thing here would solve that
it seems. It might even be cool to use the same signature. It avoids
wheel re-invention, and uses something documented and well-vetted.
And maybe the pretty-printer registration could be based on the type
signature. OTOH the signature wasn't really intended for anything
else so hijacking it may be problematic.
[Just thinking out loud ...]
Not saying there aren't other problems though.
OTOH, I wouldn't mind seeing a couple of paradigms for registering
pretty printers if it means targets that can handle better solutions
aren't left to suffer to the lowest common denominator.
next prev parent reply other threads:[~2009-06-12 16:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-07 23:11 Vladimir Prus
2009-06-10 19:25 ` Tom Tromey
2009-06-11 8:29 ` Vladimir Prus
2009-06-11 17:14 ` Paul Pluzhnikov
2009-06-12 0:52 ` Daniel Jacobowitz
2009-06-12 7:20 ` Vladimir Prus
2009-06-12 16:43 ` Doug Evans [this message]
2009-06-12 16:51 ` Daniel Jacobowitz
2009-06-12 17:12 ` Doug Evans
2009-06-12 17:06 ` Tom Tromey
2009-06-12 17:36 ` Tom Tromey
2009-06-12 17:43 ` Vladimir Prus
2009-06-15 20:23 ` Tom Tromey
2009-06-26 20:37 ` Tom Tromey
2009-06-27 10:16 ` Vladimir Prus
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=e394668d0906120943q5bcc9a92xe94b9ba199d2ffe8@mail.gmail.com \
--to=dje@google.com \
--cc=gdb@sources.redhat.com \
--cc=ppluzhnikov@google.com \
--cc=tromey@redhat.com \
--cc=vladimir@codesourcery.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