From: Tom Tromey <tromey@redhat.com>
To: Gabriel Charette <gchare@google.com>
Cc: Diego Novillo <dnovillo@google.com>,
Lawrence Crowl <crowl@google.com>,
gcc@gcc.gnu.org, Collin Winter <collinwinter@google.com>
Subject: Re: Linemap and pph
Date: Sat, 23 Jul 2011 05:46:00 -0000 [thread overview]
Message-ID: <m362mtwz3f.fsf@fleche.redhat.com> (raw)
In-Reply-To: <CAJTZ7L+VPzfrLvnR6ZDmCd29hm2OFHo+taQfLZxDqMBgwqBg1w@mail.gmail.com> (Gabriel Charette's message of "Fri, 22 Jul 2011 14:15:28 -0700")
Gabriel> We are tying to keep pph as "pluginable" as possible (Diego correct me
Gabriel> if I'm wrong), so changing the actual implementation of the linemap
Gabriel> would be our very last resort I think.
Gabriel> However since source_location aren't pointers per se, this wouldn't
Gabriel> work (at least with our current cache implementation, and changing
Gabriel> that is also last resort in my opinion)
I think something's got to give :)
Tom> Can you not just serialize the line map when creating the PPH?
Gabriel> We were wondering about that, the problem we thought is that a pph can
Gabriel> be loaded from anywhere in many different C files (which would
Gabriel> generate a different linemap entry in each case I think?). If there
Gabriel> was a way to serialize the linemap entries from the LC_ENTER entry for
Gabriel> the header file to the LC_LEAVE (i.e. ignoring builtins, command line,
Gabriel> etc.), and then directly insert those entries in a given C file
Gabriel> compilation's linemaps entries, that would be great!
Sure, I think you could probably serialize just some subset of the
linemap. It is hard to be positive, as nobody has ever tried it, and I
don't know enough about your needs to suggest what subsetting might make
sense.
The question then is whether you are certain that the other objects you
write out are guaranteed not to reference locations outside this set.
Tom
next prev parent reply other threads:[~2011-07-23 1:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-22 20:40 Gabriel Charette
2011-07-22 21:15 ` Tom Tromey
2011-07-22 22:12 ` Gabriel Charette
2011-07-23 5:46 ` Tom Tromey [this message]
2011-07-23 17:54 ` Dodji Seketeli
2011-07-25 19:34 ` Gabriel Charette
2011-07-25 22:55 ` Gabriel Charette
2011-07-26 14:46 ` Dodji Seketeli
2011-07-26 18:49 ` Gabriel Charette
2011-07-26 22:54 ` Gabriel Charette
2011-07-27 10:11 ` Dodji Seketeli
2011-07-27 14:17 ` Gabriel Charette
2011-07-27 14:26 ` Dodji Seketeli
2011-07-27 14:51 ` Gabriel Charette
2011-07-27 15:45 ` Dodji Seketeli
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=m362mtwz3f.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=collinwinter@google.com \
--cc=crowl@google.com \
--cc=dnovillo@google.com \
--cc=gcc@gcc.gnu.org \
--cc=gchare@google.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).