On Fri, 22 Jun 2018 at 18:42, Jim Ingham wrote:
>
>
>
> > On Jun 22, 2018, at 4:05 AM, Pavel Labath wrote:
> >
> > On Wed, 20 Jun 2018 at 23:21, Jim Ingham wrote:
> >>
> >> It is not uncommon that you would be parsing the DWARF for module A and
> >> find a type that is only known as a forward d
> On Jun 22, 2018, at 4:05 AM, Pavel Labath wrote:
>
> On Wed, 20 Jun 2018 at 23:21, Jim Ingham wrote:
>>
>> It is not uncommon that you would be parsing the DWARF for module A and find
>> a type that is only known as a forward declaration. In that case, lldb will
>> look through the other
On Wed, 20 Jun 2018 at 23:21, Jim Ingham wrote:
>
> It is not uncommon that you would be parsing the DWARF for module A and find
> a type that is only known as a forward declaration. In that case, lldb will
> look through the other Modules' debug info for a real definition, parse that
> and im
Part of gdb's slow startup used to be because it built its indexes manually.
But also, while gdb does do lazy ingestion of debug information it's laziness
is (or was last time I looked at it) on a compile-unit boundary, so when you
stop in a file that includes a many complex types you can end
> On Jun 21, 2018, at 8:32 AM, Frédéric Riss wrote:
>
>
>
>> On Jun 21, 2018, at 3:18 AM, Pavel Labath via Phabricator
>> wrote:
>>
>> labath added a comment.
>>
>> I am not sure this will actually solve the problems you are seeing. This may
>> avoid corrupting the internal DenseMap data
> On Jun 21, 2018, at 8:03 AM, Pavel Labath via Phabricator
> wrote:
>
> labath added a comment.
>
> In https://reviews.llvm.org/D48393#1139270, @clayborg wrote:
>
>> In https://reviews.llvm.org/D48393#1138989, @labath wrote:
>>
>>> I am not sure this will actually solve the problems you ar
> On Jun 21, 2018, at 3:18 AM, Pavel Labath via Phabricator
> wrote:
>
> labath added a comment.
>
> I am not sure this will actually solve the problems you are seeing. This may
> avoid corrupting the internal DenseMap data structures, but it will not make
> the algorithm using them actuall
> On Jun 21, 2018, at 7:58 AM, Zachary Turner wrote:
>
> Performance i get. Gdb is almost unusable for large programs because of how
> long it takes to load debug info.
Agreed. With our new DWARF5 tables, we will be even better. Or test on a mac
with dSYM files and you will get similar numbe
Performance i get. Gdb is almost unusable for large programs because of how
long it takes to load debug info.
Do you have specific numbers on memory usage? How much memory (absolute and
%) is saved by loading debug info lazily on a relatively large project?
On Thu, Jun 21, 2018 at 7:54 AM Greg Cla
> On Jun 21, 2018, at 7:47 AM, Zachary Turner wrote:
>
> Related question: Is the laziness done to save memory, startup time, or both?
Both. It allows us to fetch only what we need when we need it. Time to break at
main.cpp:123 is much quicker. Using LLDB for symbolication is much quicker as
Related question: Is the laziness done to save memory, startup time, or
both?
On Thu, Jun 21, 2018 at 7:36 AM Greg Clayton via Phabricator <
revi...@reviews.llvm.org> wrote:
> clayborg added a comment.
>
> In https://reviews.llvm.org/D48393#1138989, @labath wrote:
>
> > I am not sure this will act
> On Jun 20, 2018, at 3:14 PM, Frederic Riss via Phabricator
> wrote:
>
> friss added a comment.
>
> In https://reviews.llvm.org/D48393#1138398, @zturner wrote:
>
>> Long term I think one potentially interesting possibility for solving a lot
>> of these threading and lazy evaluation issues
12 matches
Mail list logo
