[lldb-dev] Making a new symbol provider

[Zachary Turner via lldb-dev]

Those are addresses.  Here's the situation I was encountering this on:

// foo.h
#include "bar.h"
inline int f(int n)
{
    return g(n) + 1;
}

// bar.h
inline int g(int n)
{
    return n+1;
}

// foo.cpp
#include "foo.h"
int main(int argc, char** argv)
{
    return f(argc);
}

PDB gives me back line numbers and address range grouped by file.  So I get
all of foo.h's lines, all of bar.h's lines, and all of foo.cpp's lines.  In
sorted form, the lines for g will appear inside the sequence of lines for
f.  So that's how the situation was arising.

I'll upload a patch tomorrow morning, and along with it a test (which is
how I found this to begin with).  If you look at the test you will see the
exact source code and the line / address sequences that are generated.

I think I have everything working, and I wrote some test cases to validate
my assumptions.  Which is good because every test was broken at first, so I
wouldn't have been able to fix things without them.  They shoudl also help
verify that my assumptions are correct to begin with, which hopefully makes
reviewing easier.

On Mon, Feb 29, 2016 at 5:29 PM Greg Clayton <gclayton at apple.com> wrote:

>
> > On Feb 29, 2016, at 5:09 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > Suppose you've got two line sequences.
> >
> > First sequence:
> > 4198512
> > 4198544
> > 4198547
> > 4198562
> >
> > Second sequence:
> > 4198528
> > 4198531
> > 4198537
> > 4198552
> >
> > These two line sequences overlap, and will not be inserted correctly
> into a LineTable.  This sounds like a bug to me, because as far as I can
> tell there is nothing preventing LineSequences being organized this way,
> but LineTable::InsertSequence assumes that this cannot happen.
>
> Are these addresses or line numbers? If PDB can has its line tables
> randomly ordered, you will need to read all line entries out of the PDB
> file first into one big collection of all line entries, and remember if any
> are line termination entries and then make sequences out of the large
> collection you end up with.
>
> We only expect to get one line entry for a given load address and I
> believe that is reasonable. The registration process for line entries is
> very DWARF centric right now, but I think that the end goal if having line
> table sequences in ascending order that have a single file and line for a
> given load address is a valid assumption.
>
> So it sounds like you just need to read all of your stuff into one large
> buffer and then figure out how you want to register those sequences so they
> make sense.
>
> In DWARF if you have a line tables like:
>
> 0x1000: foo.c line 1
> 0x1010: foo.c line 2
> 0x1030: foo.c line 3
> 0x1040: termination entry
>
> 0x2000: foo.c line 11
> 0x2010: foo.c line 12
> 0x2020: foo.c line 13
> 0x2050: termination entry
>
> These are both sequences that define address ranges and we always know the
> address range of each line entry because the last entry in a contiguous
> line sequence always has a last entry to define the size of the last valid
> (non termination entry) line entry.
>
> How does the PDB file format emit it line table entries? Would it be
> equivalent to the DWARF with no termination entries? Something like:
>
> 0x1000: foo.c line 1
> 0x1010: foo.c line 2
> 0x1030: foo.c line 3
>
> 0x2000: foo.c line 11
> 0x2010: foo.c line 12
> 0x2020: foo.c line 13
>
> If that is the case, how do you deal with large gaps like the gap between
> 0x1040 and 0x2000?
>
> And if I read what you are saying correctly you are saying your line
> tables might come out like:
>
> 0x1000: foo.c line 1
> 0x2000: foo.c line 11
> 0x1010: foo.c line 2
> 0x2010: foo.c line 12
> 0x1030: foo.c line 3
> 0x2020: foo.c line 13
>
> Questions:
>
> - Does PDB emit ranges for each line or just a single address?
> - Does PDB have termination entries for the equivalent of address 0x1040
> and 0x2050?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160301/cd940270/attachment-0001.html>