[PATCH] Initial pass at API design for DebugInfo/PDB

David Blaikie dblaikie at gmail.com
Mon Feb 2 15:13:57 PST 2015


On Mon, Feb 2, 2015 at 3:10 PM, Zachary Turner <zturner at google.com> wrote:

> ================
> Comment at: include/llvm/DebugInfo/PDB/IPDBDataStream.h:26
> @@ +25,3 @@
> +  virtual uint32 getRecordCount() = 0;
> +  virtual std::string getName() = 0;
> +  virtual bool getItemAtIndex(RecordType &Record) = 0;
> ----------------
> dblaikie wrote:
> > zturner wrote:
> > > dblaikie wrote:
> > > > What's this the name of?
> > > The name of the data stream (which in turn identifies what kind of
> data it has).  The stream named "FPO" for example, contains fpo data.
> > Is that useful to clients? Would there be a better API like just having
> different types (templated, perhaps) of streams?
> I actually pondered not including access to the underlying streams at
> all.  The reason is that the streams simply provide access to the raw bytes
> in the PDB file.  All of the information present in the streams is
> available through the typed methods as well.  But I figured it was useful
> still for the dumper.  From what I can tell, the dumper will be the only
> real client of the stream data, so just returning the name sems kind of
> reasonable.  Another thing is that it's not documented what all of the
> different streams that might be returned are.  So far I've observed a few
> different ones through some dumps I've run on my own, but they're not
> always the same, so there could be some we don't know about.
>

Ah, so the name is given to you by the API, but it's not just regurgitating
a value you passed in (it's not like I ask for stream "foo" and then it
gives me back a stream with the name "foo"). That makes sense then - as you
say, at least for the dumper to be able to just say "give me all the
streams" and print whatever name/streams it gets back.


>
> http://reviews.llvm.org/D7356
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150202/2d2d08b4/attachment.html>


More information about the llvm-commits mailing list