On 2017-02-28 18:36, Greg Clayton wrote:
On Feb 28, 2017, at 4:19 AM, Carlo Kok via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:
As far as I can tell from reading the source LLDB has facilities to
load a "jitted" clang fragment as an object file, load it into the
target process "run" it a
Thank you Paul. Could you paste the output of the "check-lldb" command?
The LogTest.cpp thing looks like a gcc issue I ran into earlier, I'll have
that fixed shortly.
cheers,
pl
On 28 February 2017 at 17:39, Robinson, Paul via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Also, if I do 'ninja c
I presume you meant "step over is not working" in the Subject?
The call to std::cout... ends up inserting quite a number of inlined function
calls into my_func. clang is not always great at generating coherent
line-table and inlined subroutine ranges for deeply nested inlining, so that
the ste
I look forward to seeing DWARF5 support integrated into LLDB. No problems that
I know of that you will run into. Please include me in on the LLDB related
patches for DWARF5. One particular area of interest is the emission of the new
accelerator tables and having LLDB support them. I believe the
Also, if I do 'ninja check-all' then I get a compile-time error in
lldb/unittests/Core/LogTest.cpp (line 24):
could not convert '(const char*)"log foo"' from 'const char*' to
'llvm::StringLiteral'
Thanks,
--paulr
> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.
> On Feb 28, 2017, at 4:19 AM, Carlo Kok via lldb-dev
> wrote:
>
> As far as I can tell from reading the source LLDB has facilities to load a
> "jitted" clang fragment as an object file, load it into the target process
> "run" it and unload it. Could this process be reused externally? Say fro
Thanks for the feedback! Clang will continue to emit v4 by default for quite
some time, the v5 work is just getting started.
Would someone like to be subscribed to LLVM reviews that do new v5 work? Or
just rely on us remembering to send notes to lldb-dev?
Once I get the unit headers in place, m
Thanks for catching this, should be an easy fix. I'll try to get something
in this week
On Tue, Feb 28, 2017 at 3:34 AM olizit via lldb-dev
wrote:
> Hello,
>
> As written in MSDN documentation
> https://msdn.microsoft.com/fr-fr/library/windows/desktop/ms681400%28v=vs.85%29.aspx?f=255&MSPPError=-2
https://bugs.llvm.org/show_bug.cgi?id=32090
Bug ID: 32090
Summary: DynamicLoaderPOSIXDyld crashes if an app dies before
hitting the entry breakpoint
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
As far as I can tell from reading the source LLDB has facilities to load
a "jitted" clang fragment as an object file, load it into the target
process "run" it and unload it. Could this process be reused externally?
Say from the SB or lower level apis?
What I want to accomplish is allow better
Thanks for the heads up Paul. I've tried your change on linux, and I don't
see any regressions, so it should be safe to land.
Regarding the test failures you were seeing: what is the system you were
testing this on? If it is linux, could you send me the list of failures --
I'd be interested in get
As far as I know the only dwarf v5 functionality currently implemented in
LLDB is the split dwarf support so I don't expect it to work with the new
dwarf v5 data but as long as clang emits dwarf v4 (or older) by default it
shouldn't cause any immediate problem with the test suite (we will still
hav
Hello,
Compile this sample program with clang 3.9.1 in 64bits mode
#include
int my_func(char c, double d)
{
std::cout << "c: " << c << std::endl;
std::cout << "d:" << d << std::endl;
return 0;
}
int main(int argc, char const *argv[])
{
int i = 0;
i++;
i++;
my_func('a', 10.1);
i++;
i++;
return 0
Hello,
As written in MSDN documentation
https://msdn.microsoft.com/fr-fr/library/windows/desktop/ms681400%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
UnDecorateSymbolName function is not thread safe and must be mutex guarded.
Thanks,
Olivier
___
lldb
14 matches
Mail list logo
