I believe I have tracked down an interesting bug which related to LLDBs
expression parser.
In my target program I have a math library, a shared object which makes
use of clangs __attribute__((overloadable)) extension for C99. This
causes the the function names in the math library to be mangle
Thanks Siva,
This indeed looks somewhat related to the problems we are seeing here.
I'm just having a read of your patch now and going to try it out here.
On 05/11/2015 18:24, Siva Chandra wrote:
On Thu, Nov 5, 2015 at 9:43 AM, Aidan Dodds via lldb-dev
wrote:
I believe I have tracked do
Hi Greg,
It turns out that the problem I was having was fixed when I patched a
bug in DwarfSymbolFile:
http://reviews.llvm.org/D14538
But thanks for the additional info.
Aidan
On 12/11/2015 17:54, Greg Clayton wrote:
On Nov 5, 2015, at 9:43 AM, Aidan Dodds via lldb-dev
wrote:
I believe
First off thanks for opening that up to the mailing list, it will be
good if discussion of this is useful to others.
From the python 3.5 case:
I'm not using ninja.build, but instead just compiling from the visual
studio ide. However, the custom build step I think you were referring
to for fin
Just to chip in on this thread.
I regularly build X64 LLDB using Visual Studio, but I only use it for
debugging remote targets.
I have noticed the gtests linking error, but unfortunately due to tight
time constraints I've not been free to fix it.
I tend to 'unload' all of the projects in Visual
Hi all,
I pulled in recent changes to upstream llvm, clang and lldb and it seems
to have tipped my windows build over the edge, and its complaining that
my object files have exceeded the section limit.
This error is raised while building the clang libraries. Has anyone
else seen this problem whi
platforms as well.
If MSVC 2015 instead just happens to generate say one extra section
per function, then we should probably use bigobj.
On Tue, Feb 9, 2016 at 3:55 AM, Aidan Dodds via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:
Hi all,
I pulled in recent changes to upst
The GDB RSP, which LLDB RSP is derived from is certainly state-full and
maintains an notion of the current thread for queries (reading
registers, etc..) and for execution commands (stepping), see the 'H' packet.
The RSP has evolved quite a bit however and extended packets were
introduced that do
At Codeplay we are currently building on windows using a split of MSVC
2013 and MSVC 2015.
In theory we are happy to move entirely to 2015, but until then we would
have to work around any 2013 breakages.
On 29/03/2016 16:16, Pavel Labath via lldb-dev wrote:
Zachary, all,
after overcoming som
Hello all,
It seems that different LLVM backends (ARM, MIPS, X86) can output a
different line number for PROLOGUE_END in the DWARF line table.
Say I have a function as follows:
1. int my_function( int arg1 )
2. {
3.some_code();
4.
At -O0 I am seeing the PROLOGUE_END set on the fu
anything it wants to.
Greg
On Aug 31, 2015, at 4:22 AM, Aidan Dodds via lldb-dev
wrote:
Hello all,
It seems that different LLVM backends (ARM, MIPS, X86) can output a different
line number for PROLOGUE_END in the DWARF line table.
Say I have a function as follows:
1. int my_function( int
11 matches
Mail list logo
