Hey Jim,
We just noticed that 'target.experimental.inject-local-vars' is true by
default. If we disable that experimental the performance for expression
evaluation is significantly better.
>From the flag description:
"If true, inject local variables explicitly into the expression text. This
will
use "test", so it doesn't actually have to make that instantiation. In the
> case where this works with gdb, did you build with clang or did you build
> with gcc? If the latter, this might be working for gdb because gcc emits
> code for the int template instantiation whe
t; Not that that really matters for what lldb would have to do, but it would
> be interesting to know...
>
> Jim
>
>
>
> > On Jul 23, 2019, at 4:22 PM, Scott Funkenhauser via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hey,
> >
&
Hey,
I've noticed that evaluating expressions involving templated classes seems
to have some unexpected behavior.
I've created the following sample code to reproduce the issue:
template class foo
{
uint32_t data;
};
foo test;
int main() {
foo test2;
return 0;
}
I've set a breakpoint
t's what the
> gnu linkers generated. But, as it seems that this field can be of any
> size, maybe it's time to teach UUID how to handle the new reality.
>
> Have you looked at how hard would it be to implement something like that?
>
> pl
> On Wed, 20 Jun 2018 at 16:05, S
Hey guys,
LLDB uses source/Utility/UUID.cpp to store the build ID. This class only
supports 16 or 20 byte IDs.
When parsing the .note.gnu.build-id ELF section, any build ID between 4 and
20 bytes will be parsed and saved (which will silently fail if the size
isn't 16 or 20 bytes)
> This is a known issue, though I did not expect it to have that much of an
> impact. In fact, I have trouble reconciling this fact with your earlier
> statement that second and subsequent runs are much faster. The SO entry
> loading is something that has to happen on every run, so I don't see
DWARF sections
should be drastically reduced?
On Tue, Apr 24, 2018 at 4:36 PM Greg Clayton <clayb...@gmail.com> wrote:
>
>
> On Apr 24, 2018, at 12:26 PM, Scott Funkenhauser via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hey guys,
>
> I'm trying to track d
of the scan until you try to do something like a
> breakpoint by name.
>
>
> J
>
> > On Apr 24, 2018, at 12:26 PM, Scott Funkenhauser via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hey guys,
> >
> > I'm trying to track down an issu
Hey guys,
I'm trying to track down an issue I'm seeing where dlopen takes
significantly longer to execute when LLDB is attached vs GDB (I've attached
a simple program that I used to reproduce the issue).
I was wondering if anybody had any idea what might be contributing to the
additional
lized the full implications of this when it was being added.
> Patches fixing this would be very wellcome.
>
> On 19 April 2017 at 15:17, Scott Funkenhauser via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hey,
>>
>> I'm exploring using lldb-mi and lldb-server to
Hey,
I'm exploring using lldb-mi and lldb-server to remotely debug a process
running on a Linux host. I'm running into an issue where lldb-mi is
failing to load the ELF section headers from the remote process's memory
for certain shared libraries.
Looking at ObjectFileELF:GetSectionHeaderInfo I
12 matches
Mail list logo
