[lldb-dev] [Bug 25296] New: LLDB have a lof of strict aliasing violation (based on GCC warnings)
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 Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: tbergham...@google.com CC: llvm-b...@lists.llvm.org Classification: Unclassified Compiling LLDB with GCC produces a lot of strict-aliasing warning. These warnings are currently turned of (in LLDBConfig.cmake) to reduce the noise they generate, but they should be fixed at some point as they might be real problems. After fixing all (most) of them the warning should be re-enabled to prevent the regression in new strict aliasing violations. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] llvm assertion while evaluating expressions for MIPS on Linux
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 is ".L").
The subclasses of llvm::MCAsmInfo sets PrivateGlobalPrefix to whatever value
they want to use for temporary symbol.
MIPS sets this to "$". (and X86/ARM uses ".L")
Since the function name "$__lldb_valid_pointer_check" starts with "$" it
matches with PrivateGlobalPrefix for MIPS and hence it is marked as temporary.
Its fine for all x86/x86_64/arm and arm64 variants because they all use symbol
other than "$" (i.e ".L") as their PrivateGlobalPrefix.
As you mentioned we cannot remove "$" from function name because it may
conflict with symbols from system libraries or user binaries,
so do you think removing C Language linkage from function
"$__lldb_valid_pointer_check" can be a solution? or do you have a better
solution to this issue?
Regards,
Bhushan
-Original Message-
From: Greg Clayton [mailto:gclay...@apple.com]
Sent: 20 October 2015 23:56
To: Greg Clayton
Cc: Bhushan Attarde; lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] llvm assertion while evaluating expressions for MIPS on
Linux
My guess is that there is a different temporary symbol for differing
architectures and possibly depending on which file format (mach-o or ELF) you
are targeting. MIPS probably happens to use '$'. I know mach-o files use "L" as
the temporary symbol prefix, ELF tends to use '.'. Not sure where this would be
abstracted in LLVM or if it is just built into the assemblers directly for each
arch... If you can find out where this can be detected within LLVM, we can make
sure we don't use any temporary prefixes in symbol names and work around this
issue. We need to make sure that any functions we generate and JIT up and
insert into the program do not conflict with _any_ symbol that could be in any
system libraries or user binaries. This is why we used '$' in the first place.
Greg
> On Oct 20, 2015, at 11:11 AM, Greg Clayton via lldb-dev
> wrote:
>
> What is this not happening on any other architecture? Is the "$" special for
> MIPS and not for other architectures? We really don't want to remove the '$'
> as we want the symbol to be unique. The '$' symbol is fine for all
> x86/x86_64/arm and arm64 variants...
>
> Greg
>
>
>> On Oct 19, 2015, at 11:30 PM, Bhushan Attarde via lldb-dev
>> wrote:
>>
>> Hi,
>>
>> I am facing issue (llvm assertion) in evaluating expressions for MIPS on
>> Linux.
>>
>> (lldb) p fooptr(a,b)
>> lldb: /home/battarde/git/llvm/lib/MC/ELFObjectWriter.cpp:791: void
>> {anonymous}::ELFObjectWriter::computeSymbolTable(llvm::MCAssembler&, const
>> llvm::MCAsmLayout&, const SectionIndexMapTy&, const RevGroupMapTy&,
>> {anonymous}::ELFObjectWriter::SectionOffsetsTy&): Assertion `Local ||
>> !Symbol.isTemporary()' failed.
>>
>> I debugged it and found that, LLDB inserts calls to dynamic checker function
>> for pointer validation at appropriate locations in expression’s IR.
>>
>> The issue is that this checker function’s name (hard-coded in LLDB in
>> lldb\source\Expression\IRDynamicChecks.cpp) starts with “$” i.e
>> “$__lldb_valid_pointer_check”.
>> While creating a MCSymbol (MCContext::createSymbol() in
>> llvm/lib/MC/MCContext.cpp) for this function llvm detects the name starts
>> with “$” and marks that symbol as ‘temporary’ symbol (PrivateGlobalPrefix is
>> '$' for MIPS) Further while computing a symbol table in
>> ELFObjectWriter::computeSymbolTable() the assertion triggers because this
>> symbol is 'temporary'.
>>
>> I tried couple of things that solves this issue for MIPS.
>>
>> 1. Remove '$' from the function name.
>> 2. Remove "C Language linkage" from the dynamic pointer validation
>> function i.e the below piece of code in
>> lldb\source\Expression\IRDynamicChecks.cpp
>> -
>> static const char g_valid_pointer_check_text[] = "extern \"C\"
>> void\n"
>> "$__lldb_valid_pointer_check (unsigned char *$__lldb_arg_ptr)\n"
>> "{\n"
>> "unsigned char $__lldb_local_val = *$__lldb_arg_ptr;\n"
>> "}";
>> -
>> -
>>
>> becomes
>>
>>
>> static const char g_valid_pointer_check_text[] = "void\n"
>> "$__lldb_valid_pointer_check (unsigned char *$__lldb_arg_ptr)\n"
>> "{\n"
>> "unsigned char $__lldb_local_val = *$__lldb_arg_ptr;\n"
>> "}";
>>
>>
>> Removing C Language linkage will enable mangling and will mangle
>> "$__lldb_valid_pointer_check" to something like
>> "_Z27$__lldb_valid_pointer_checkPh".
>> So the mangled name won't start with '$' and the symbol will not be marked
>>
Re: [lldb-dev] [BUG?] Confusion between translation units?
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 blame. This is likely a problem with your build scripts. In any case, the compiler is responsible for this mess. > It sounds like you fixed your symlink issue. So a few questions: > 1 - do you have just one type now in your libmwcgir_vm_rt.dylib.dSYM when you > type: > > (lldb) image lookup -t "iplist llvm::ilist_traits >" > > If so, then you will need to find other competing definitions in other shared > libraries and see if any of them differ by comparing the full "clang_type" > value. Yeah, after resolving the symlink, I realized that there are two different paths. I'm attempting to fix my build system. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] llvm assertion while evaluating expressions for MIPS on Linux
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, 2015, at 5:03 AM, Bhushan Attarde
> wrote:
>
> 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 is ".L").
> The subclasses of llvm::MCAsmInfo sets PrivateGlobalPrefix to whatever value
> they want to use for temporary symbol.
> MIPS sets this to "$". (and X86/ARM uses ".L")
>
> Since the function name "$__lldb_valid_pointer_check" starts with "$" it
> matches with PrivateGlobalPrefix for MIPS and hence it is marked as temporary.
> Its fine for all x86/x86_64/arm and arm64 variants because they all use
> symbol other than "$" (i.e ".L") as their PrivateGlobalPrefix.
>
> As you mentioned we cannot remove "$" from function name because it may
> conflict with symbols from system libraries or user binaries,
> so do you think removing C Language linkage from function
> "$__lldb_valid_pointer_check" can be a solution? or do you have a better
> solution to this issue?
>
> Regards,
> Bhushan
>
>
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com]
> Sent: 20 October 2015 23:56
> To: Greg Clayton
> Cc: Bhushan Attarde; lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] llvm assertion while evaluating expressions for MIPS
> on Linux
>
> My guess is that there is a different temporary symbol for differing
> architectures and possibly depending on which file format (mach-o or ELF) you
> are targeting. MIPS probably happens to use '$'. I know mach-o files use "L"
> as the temporary symbol prefix, ELF tends to use '.'. Not sure where this
> would be abstracted in LLVM or if it is just built into the assemblers
> directly for each arch... If you can find out where this can be detected
> within LLVM, we can make sure we don't use any temporary prefixes in symbol
> names and work around this issue. We need to make sure that any functions we
> generate and JIT up and insert into the program do not conflict with _any_
> symbol that could be in any system libraries or user binaries. This is why we
> used '$' in the first place.
>
> Greg
>
>> On Oct 20, 2015, at 11:11 AM, Greg Clayton via lldb-dev
>> wrote:
>>
>> What is this not happening on any other architecture? Is the "$" special for
>> MIPS and not for other architectures? We really don't want to remove the '$'
>> as we want the symbol to be unique. The '$' symbol is fine for all
>> x86/x86_64/arm and arm64 variants...
>>
>> Greg
>>
>>
>>> On Oct 19, 2015, at 11:30 PM, Bhushan Attarde via lldb-dev
>>> wrote:
>>>
>>> Hi,
>>>
>>> I am facing issue (llvm assertion) in evaluating expressions for MIPS on
>>> Linux.
>>>
>>> (lldb) p fooptr(a,b)
>>> lldb: /home/battarde/git/llvm/lib/MC/ELFObjectWriter.cpp:791: void
>>> {anonymous}::ELFObjectWriter::computeSymbolTable(llvm::MCAssembler&, const
>>> llvm::MCAsmLayout&, const SectionIndexMapTy&, const RevGroupMapTy&,
>>> {anonymous}::ELFObjectWriter::SectionOffsetsTy&): Assertion `Local ||
>>> !Symbol.isTemporary()' failed.
>>>
>>> I debugged it and found that, LLDB inserts calls to dynamic checker
>>> function for pointer validation at appropriate locations in expression’s IR.
>>>
>>> The issue is that this checker function’s name (hard-coded in LLDB in
>>> lldb\source\Expression\IRDynamicChecks.cpp) starts with “$” i.e
>>> “$__lldb_valid_pointer_check”.
>>> While creating a MCSymbol (MCContext::createSymbol() in
>>> llvm/lib/MC/MCContext.cpp) for this function llvm detects the name starts
>>> with “$” and marks that symbol as ‘temporary’ symbol (PrivateGlobalPrefix
>>> is '$' for MIPS) Further while computing a symbol table in
>>> ELFObjectWriter::computeSymbolTable() the assertion triggers because this
>>> symbol is 'temporary'.
>>>
>>> I tried couple of things that solves this issue for MIPS.
>>>
>>> 1. Remove '$' from the function name.
>>> 2. Remove "C Language linkage" from the dynamic pointer validation
>>> function i.e the below piece of code in
>>> lldb\source\Expression\IRDynamicChecks.cpp
>>> -
>>> static const char g_valid_pointer_check_text[] = "extern \"C\"
>>> void\n"
>>> "$__lldb_valid_pointer_check (unsigned char *$__lldb_arg_ptr)\n"
>>> "{\n"
>>> "unsigned char $__lldb_local_val = *$__lldb_arg_ptr;\n"
>>> "}";
>>> -
>>> -
>>>
>>> becomes
>>>
>>>
>>> static const char
Re: [lldb-dev] [BUG?] Confusion between translation units?
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: >> > > 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 blame. > > This is likely a problem with your build scripts. In any case, the > compiler is responsible for this mess. > >> It sounds like you fixed your symlink issue. So a few questions: >> 1 - do you have just one type now in your libmwcgir_vm_rt.dylib.dSYM when >> you type: >> >> (lldb) image lookup -t "iplist> llvm::ilist_traits >" >> >> If so, then you will need to find other competing definitions in other >> shared libraries and see if any of them differ by comparing the full >> "clang_type" value. > > Yeah, after resolving the symlink, I realized that there are two > different paths. I'm attempting to fix my build system. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] PSA: Python "print" statement disabled in trunk
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" has been added. This line causes the interpreter to require the print function instead of the print statement. A quick primer on the print function: Old way: print x New way: print(x) Old way: print x,# no newline at end of file New way: print(x, end='') Old way: print << my_file, foo# print to a file New way: print(foo, file=my_file) Let me know if anyone has any questions or issues with this patch. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 25300] New: Certain environment variables crash lldb-server
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 Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: bob.eric.nel...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
