https://llvm.org/bugs/show_bug.cgi?id=25300
Bug ID: 25300
Summary: Certain environment variables crash lldb-server
Product: lldb
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
P
If you sync to tip, you will pull in r251121, which disables the use of the
print statement in Python. This is because in Python 3, the print
statement has been removed in favor of the print function. You will see
that that the top of every file, the line "from __future__ import
print_function" h
I guess LLDB was just helping your resolve build issues and make your product
better... :-)
Let us know how things go once you get your build fixed.
Greg
> On Oct 23, 2015, at 9:45 AM, Ramkumar Ramachandra wrote:
>
> Hi,
>
> On Wed, Oct 21, 2015 at 2:27 PM, Greg Clayton wrote:
>>
>
>
What happens if we go with "_$" as our private prefix? Or maybe "lldb$"? Would
this avoid the issue and fix things for MIPS? I would rather us have a
consistent private naming scheme across all architectures. Let me know if you
can try that out and let us know if this works.
Greg
> On Oct 23,
Hi,
On Wed, Oct 21, 2015 at 2:27 PM, Greg Clayton wrote:
>
Atleast, can we have lldb report a nicer error?
There is conflicting DWARF information for type ilist...:
/sandbox/rramacha/3p/derived/List.h
/sandbox/rramacha/3p/install/List.h
/sandbox/rramacha/idivide/bin/libmwcgir_vm.so is to
Hi Greg,
Thanks for your reply.
There are different temporary symbols for different architectures and file
formats.
As far as I could see, llvm::MCAsmInfo class has a member "PrivateGlobalPrefix"
which specifies this temporary symbol.
The default value for PrivateGlobalPrefix is 'L' (for ELF it
https://llvm.org/bugs/show_bug.cgi?id=25296
Bug ID: 25296
Summary: LLDB have a lof of strict aliasing violation (based on
GCC warnings)
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
S
