[lldb-dev] [Bug 17384] lldb is unaware of the linux-vdso.so/linux-gate.so virtual shared library
https://llvm.org/bugs/show_bug.cgi?id=17384 ravithejaw...@gmail.com changed: What|Removed |Added CC||ravithejaw...@gmail.com Assignee|lldb-dev@lists.llvm.org |ravithejaw...@gmail.com -- 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] lldb-gtest scheme and target added to Xcode project
Nice! Out of curiosity, do all the unittests pass? (I expect they do, as they do everywhere else, just wondering) On Sun, Oct 25, 2015 at 2:57 PM Todd Fiala via lldb-dev < lldb-dev@lists.llvm.org> wrote: > This should be fixed with: > $ svn commit > unittests/Editline/CMakeLists.txt > Transmitting file data . > Committed revision 251264. > > On Sun, Oct 25, 2015 at 2:55 PM, Todd Fiala wrote: > >> Okay this broke the cmake Linux build. I'm fixing that now... >> >> On Sun, Oct 25, 2015 at 2:49 PM, Todd Fiala wrote: >> >>> Hi all, >>> >>> I've taken a stab at getting the gtests in lldb/unittests to compile and >>> run on Xcode. I just checked this in. There's a new scheme called >>> lldb-gtest. If you run that in Xcode, it should build the DebugClang >>> variant of lldb and link against the gtest libraries that come with clang. >>> The output goes out to the console when run. >>> >>> I don't currently have this hooked into any kind of aggregate target >>> yet. I want to make sure this works everywhere and doesn't break anything >>> before I make anything depend on it. >>> >>> I used a public OS X (10.11) and public Xcode (7.1, released this past >>> week) to do the changes. Please let me know if you use Xcode and if you >>> find that this target breaks (perhaps with an older version of Xcode). >>> >>> I put in a placeholder do-nothing gtest for our Editline code, partially >>> as a canary to see if I break any of the build bots. I'll be adding some >>> code there as soon as I know that I plugged it in right on the cmake side. >>> >>> Thanks! >>> -- >>> -Todd >>> >> >> >> >> -- >> -Todd >> > > > > -- > -Todd > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] command line for running the format checker?
git clang-format should do it. There are two things it doesn't handle: 1) It puts constructor initializer list separators (comma and colon) at the beginning of each line instead of at the end of each line. 2) It doesn't put return type on a separate line for declarations (but it does for definitions). I should probably take some time and go fix those 2 issues in clang-format... For anyone not using git, `git clang-format` essentially runs the script `llvm/tools/clang/tools/clang-format/git-clang-format`. You can run that script manually with --help to get more information about how to use it without git. And there may also be a way to integrate it into svn so you can write something like `svn clang-format` On Sun, Oct 25, 2015 at 8:57 AM Todd Fiala via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi all, > > What's the proper command line invocation to run our sources through to > get proper LLVM formatting and other desired fix-ups? > > Thanks! > > -- > -Todd > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Using DYLD_LIBRARY_PATH and lldb
I am surprised that this doesn't work as we make an effort to pass the current environment down to any processes that you spawn by default (at least on MacOSX we do), but the solution is easy: use the --environment variable with the "process launch" command: (lldb) process launch --environment DYLD_LIBRARY_PATH= -- arg1 arg2 arg3 or using the short -v option: (lldb) process launch -v DYLD_LIBRARY_PATH= -- arg1 arg2 arg3 r is an alias to "process launch --". Note that "process launch" can have arguments and the arguments you want to pass to your program might have options, so you can terminate your "process launch" arguments with "--" so that you can add your program arguments: (lldb) process launch --environment DYLD_LIBRARY_PATH= -- --program-option=123 --environment BAR=BAZ Note that I actually used an option "--environment BAR=BAZ" that I am passing to the program to be debugged... It is better to use --environment because then your current LLDB or any processes that LLDB spawns won't have that environment variable set. Hope this helps. Greg Clayton > On Oct 23, 2015, at 1:11 AM, Haakon Sporsheim via lldb-dev > wrote: > > Hi. > > I'm fairly new to lldb, been using gdb most of my life. > > I'm currently hacking on a small library which I'm building without > installing. Usually I'm running tests for the library also without > installing, but rather using DYLD_LIBRARY_PATH in this manner: > DYLD_LIBRARY_PATH= mytestbinary > > On linux using gdb when I want to debug an issue I usually just stick > gdb in there, which I can't do with lldb on darwin it seems: > DYLD_LIBRARY_PATH= lldb mytestbinary > > lldb gives me this result: > (lldb) target create "" > Current executable set to '' (x86_64). > (lldb) r > Process 4904 launched: '' (x86_64) > dyld: Library not loaded: /usr/local/lib/ > Referenced from: > Reason: image not found > Process 4904 stopped > * thread #1: tid = 0xfe39, 0x7fff5fc01075 dyld`dyld_fatal_error + > 1, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0) >frame #0: 0x7fff5fc01075 dyld`dyld_fatal_error + 1 > dyld`dyld_fatal_error: > -> 0x7fff5fc01075 <+1>: nop > > dyld`dyldbootstrap::start: >0x7fff5fc01076 <+0>: pushq %rbp >0x7fff5fc01077 <+1>: movq %rsp, %rbp >0x7fff5fc0107a <+4>: pushq %r15 > (lldb) > > so it's not picking up the dylib from DYLD_LIBRARY_PATH. > > I guess my question is whether this is a bug or not? Am I doing > anything wrong, or should I not use DYLD_LIBRARY_PATH this way? Any > suggestions and/or education would be appreciated! > To work around this issue I've used 'install_name_tool -change old new > ' which obviously works. > > Thanks, best regards > Haakon Sporsheim > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ 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
I spoke with Sean Callanan on this and he suggests you submit a patch where we
use "_$" to Phabricator and then we can OK this and get this into LLDB for
good. Thanks for looking into this.
Greg
> On Oct 25, 2015, at 10:24 PM, Bhushan Attarde
> wrote:
>
> Hi Greg,
>
> I tried using "_$" and "lldb$" as our private prefix, both of these solves
> the issue and works fine for MIPS.
>
> -Regards,
> Bhushan
>
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com]
> Sent: 23 October 2015 22:29
> To: Bhushan Attarde
> Cc: lldb-dev@lists.llvm.org
> Subject: 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 'tempo
Re: [lldb-dev] command line for running the format checker?
Awesome, thanks Zachary! On Mon, Oct 26, 2015 at 9:38 AM, Zachary Turner wrote: > git clang-format should do it. There are two things it doesn't handle: > > 1) It puts constructor initializer list separators (comma and colon) at > the beginning of each line instead of at the end of each line. > 2) It doesn't put return type on a separate line for declarations (but it > does for definitions). > > I should probably take some time and go fix those 2 issues in > clang-format... > > For anyone not using git, `git clang-format` essentially runs the script > `llvm/tools/clang/tools/clang-format/git-clang-format`. You can run that > script manually with --help to get more information about how to use it > without git. And there may also be a way to integrate it into svn so you > can write something like `svn clang-format` > > On Sun, Oct 25, 2015 at 8:57 AM Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi all, >> >> What's the proper command line invocation to run our sources through to >> get proper LLVM formatting and other desired fix-ups? >> >> Thanks! >> >> -- >> -Todd >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > -- -Todd ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb-gtest scheme and target added to Xcode project
Yes, they do. On Mon, Oct 26, 2015 at 9:34 AM, Zachary Turner wrote: > Nice! Out of curiosity, do all the unittests pass? (I expect they do, as > they do everywhere else, just wondering) > > On Sun, Oct 25, 2015 at 2:57 PM Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> This should be fixed with: >> $ svn commit >> unittests/Editline/CMakeLists.txt >> Transmitting file data . >> Committed revision 251264. >> >> On Sun, Oct 25, 2015 at 2:55 PM, Todd Fiala wrote: >> >>> Okay this broke the cmake Linux build. I'm fixing that now... >>> >>> On Sun, Oct 25, 2015 at 2:49 PM, Todd Fiala >>> wrote: >>> Hi all, I've taken a stab at getting the gtests in lldb/unittests to compile and run on Xcode. I just checked this in. There's a new scheme called lldb-gtest. If you run that in Xcode, it should build the DebugClang variant of lldb and link against the gtest libraries that come with clang. The output goes out to the console when run. I don't currently have this hooked into any kind of aggregate target yet. I want to make sure this works everywhere and doesn't break anything before I make anything depend on it. I used a public OS X (10.11) and public Xcode (7.1, released this past week) to do the changes. Please let me know if you use Xcode and if you find that this target breaks (perhaps with an older version of Xcode). I put in a placeholder do-nothing gtest for our Editline code, partially as a canary to see if I break any of the build bots. I'll be adding some code there as soon as I know that I plugged it in right on the cmake side. Thanks! -- -Todd >>> >>> >>> >>> -- >>> -Todd >>> >> >> >> >> -- >> -Todd >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > -- -Todd ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [BUG?] Confusion between translation units?
Okay, I'm stuck again. Let's back up and see what's happening: ~/src$ git clone llvm/ ~/src$ mkdir llvm-build/ ~/src/llvm-build$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug ../llvm ~/src/llvm-build$ ninja Now, ~/src/llvm-build/lib/libLLVMCore.a contains DWARF information that points to files ~/src/llvm/include/llvm/ADT/ilist.h, ~/src/llvm/lib/IR/Core.cpp etc. ~/src/llvm-build$ ninja install The *.a files are copied to /usr/local/lib, but the *.h files are also copied to /usr/local/include/llvm. The DWARF information is not rewritten as part of the "install". ~/src/fooapp$ clang++ -g -I/usr/local/include -L/usr/local/lib ... The fooapp binary is going to contain DWARF information pointing to /usr/local/include/llvm/ADT/ilist.h (because I did -I) _and_ ~/src/llvm/include/llvm/ADT/ilist.h (because of libLLVMCore.a). lldb crashes. gdb hums along just fine in the face of this conflict (the codebase is enormous; sorry, I couldn't find out how exactly). Now, I cannot "fix" my build by -I'ing ~/src/llvm/include because some essential headers are build artifacts. The only thing I can do is to try and put a plist into the dSYM (which doesn't seem to work either, or I'm doing something wrong). In the general case, there's nothing special about my build: this problem needs to be solved in lldb for the general audience. Please advise. Thanks. Ram On Fri, Oct 23, 2015 at 1:00 PM, Greg Clayton wrote: > 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
Re: [lldb-dev] [BUG?] Confusion between translation units?
So when LLDB parses the DW_AT_decl_file attributes, it uses the files from the
line table for the current compile unit. Each of those files is passed through
the module source remapping function:
bool
Module::RemapSourceFile (const char *path, std::string &new_path) const
{
Mutex::Locker locker (m_mutex);
return m_source_mappings.RemapPath(path, new_path);
}
So if you have a plist, it should be being added to this m_source_mappings
list. You might want to debug what is happening by stepping through:
SymbolVendorMacOSX::CreateInstance()
for the dSYM file that is being used by your build. Inside the "if
(XMLDocument::XMLEnabled())" statement is where we get the path remappings.
A quick note on the plist files in the dSYM: you must create one for each UUID
plist for each architecture slice inside the dSYM bundle:
/tmp/foo.dSYM/Contents/Resources/9FE9CADA-7460-3F80-B881-42443C5FA2E1.plist
/tmp/foo.dSYM/Contents/Resources/DF977301-4A63-32ED-9939-1EE3122D18D4.plist
And an example plist for you would need to look like:
% cat
/tmp/foo.dSYM/Contents/Resources/9FE9CADA-7460-3F80-B881-42443C5FA2E1.plist
http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
DBGBuildSourcePath
~/src/llvm/include/llvm
DBGSourcePath
/usr/local/include/llvm
> On Oct 26, 2015, at 11:00 AM, Ramkumar Ramachandra wrote:
>
> Okay, I'm stuck again. Let's back up and see what's happening:
>
> ~/src$ git clone llvm/
> ~/src$ mkdir llvm-build/
> ~/src/llvm-build$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug ../llvm
> ~/src/llvm-build$ ninja
>
> Now, ~/src/llvm-build/lib/libLLVMCore.a contains DWARF information
> that points to files ~/src/llvm/include/llvm/ADT/ilist.h,
> ~/src/llvm/lib/IR/Core.cpp etc.
>
> ~/src/llvm-build$ ninja install
>
> The *.a files are copied to /usr/local/lib, but the *.h files are also
> copied to /usr/local/include/llvm. The DWARF information is not
> rewritten as part of the "install".
>
> ~/src/fooapp$ clang++ -g -I/usr/local/include -L/usr/local/lib ...
>
> The fooapp binary is going to contain DWARF information pointing to
> /usr/local/include/llvm/ADT/ilist.h (because I did -I) _and_
> ~/src/llvm/include/llvm/ADT/ilist.h (because of libLLVMCore.a).
>
> lldb crashes. gdb hums along just fine in the face of this conflict
> (the codebase is enormous; sorry, I couldn't find out how exactly).
>
> Now, I cannot "fix" my build by -I'ing ~/src/llvm/include because some
> essential headers are build artifacts. The only thing I can do is to
> try and put a plist into the dSYM (which doesn't seem to work either,
> or I'm doing something wrong). In the general case, there's nothing
> special about my build: this problem needs to be solved in lldb for
> the general audience.
>
> Please advise.
>
> Thanks.
>
> Ram
>
> On Fri, Oct 23, 2015 at 1:00 PM, Greg Clayton wrote:
>> 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
Re: [lldb-dev] [BUG?] Confusion between translation units?
After speaking with Adrian Prantl over here we came up with a solution.
Currently we do this when uniquing types:
// Only try and unique the type if it has a name.
if (type_name_const_str &&
dwarf->GetUniqueDWARFASTTypeMap().Find (type_name_const_str,
die,
decl,
byte_size_valid ? byte_size : -1,
*unique_ast_entry_ap))
{
// We have already parsed this type or from another
// compile unit. GCC loves to use the "one definition
// rule" which can result in multiple definitions
// of the same class over and over in each compile
// unit.
type_sp = unique_ast_entry_ap->m_type_sp;
if (type_sp)
{
dwarf->GetDIEToType()[die.GetDIE()] = type_sp.get();
return type_sp;
}
}
We try to find a type by name and Declaration. We need to do this for all
language except for C++ because C++ has the one definition rule where a type
must be unique in a decl context (all types llvm::foo::bar must be the same).
Since this only applies to C++ we could do something like:
if (type_name_const_str)
{
LanguageType die_language = die.GetLanguage();
bool handled = false;
if (Language::LanguageIsCPlusPlus(die_language))
{
std::string qualified_name;
if (die.GetQualifiedName (qualified_name))
{
handled = true;
ConstString const_qualified_name(qualified_name);
if (dwarf->GetUniqueDWARFASTTypeMap().Find (const_qualified_name,
die,
Declaration(),
byte_size_valid ? byte_size :
-1,
*unique_ast_entry_ap))
{
type_sp = unique_ast_entry_ap->m_type_sp;
if (type_sp)
{
dwarf->GetDIEToType()[die.GetDIE()] = type_sp.get();
return type_sp;
}
}
}
}
if (!handled)
{
if (dwarf->GetUniqueDWARFASTTypeMap().Find (type_name_const_str,
die,
decl,
byte_size_valid ? byte_size :
-1,
*unique_ast_entry_ap))
{
type_sp = unique_ast_entry_ap->m_type_sp;
if (type_sp)
{
dwarf->GetDIEToType()[die.GetDIE()] = type_sp.get();
return type_sp;
}
}
}
}
Note that for C++ we get the fully qualified name and we pass in an empty
Declaration() so they all will compare to the same thing. This would solve our
current issue. We would also need to add the items to this map in the same way:
for C++ get the fully qualified name and add the entry to the map with the
fully qualified name and an empty Declaration...
Can you try this solution out and see if it fixes our issues?
Greg
> On Oct 26, 2015, at 11:13 AM, Greg Clayton via lldb-dev
> wrote:
>
> So when LLDB parses the DW_AT_decl_file attributes, it uses the files from
> the line table for the current compile unit. Each of those files is passed
> through the module source remapping function:
>
> bool
> Module::RemapSourceFile (const char *path, std::string &new_path) const
> {
>Mutex::Locker locker (m_mutex);
>return m_source_mappings.RemapPath(path, new_path);
> }
>
> So if you have a plist, it should be being added to this m_source_mappings
> list. You might want to debug what is happening by stepping through:
>
> SymbolVendorMacOSX::CreateInstance()
>
> for the dSYM file that is being used by your build. Inside the "if
> (XMLDocument::XMLEnabled())" statement is where we get the path remappings.
>
> A quick note on the plist files in the dSYM: you must create one for each
> UUID plist for each architecture slice inside the dSYM bundle:
>
> /tmp/foo.dSYM/Contents/Resources/9FE9CADA-7460-3F80-B881-42443C5FA2E1.plist
> /tmp/foo.dSYM/Contents/Resources/DF977301-4A63-32ED-9939-1EE3122D18D4.plist
>
> And an example plist for you would need to look like:
>
> % cat
> /tmp/foo.dSYM/Contents/Resources/9FE9CADA-7460-3F80-B881-42443C5FA2E1.plist
>
> "http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
>
>
> DBGBuildSourcePath
> ~/src/llvm/include/llvm
> DBGSourcePath
> /usr/local/include/llvm
>
>
>
>
>> On Oct 26, 2015, at 11:00 AM, Ramkumar Ramachandra
>> wrote:
>>
>> Okay, I'm stuck again. Let's back up and see what's happening:
>>
>> ~/src$ git clone llvm/
>> ~/src$ mkdir llvm-build/
>> ~/src/llvm-build$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug ../llvm
>> ~/src/llvm-build$ ninja
>>
>> Now, ~/src/llvm-build/lib/libLLVMCore.a contains DWARF information
>> that points to files ~/src/llvm/include/llvm/ADT/ilist.h,
>> ~/src/llvm/lib/IR/Core.cpp etc.
>>
>> ~/src/llvm-build$ ninja install
>>
>> Th
Re: [lldb-dev] [BUG?] Confusion between translation units?
Greg, Greg Clayton wrote: > Note that for C++ we get the fully qualified name and we pass in an empty > Declaration() so they all will compare to the same thing. This would solve > our current issue. We would also need to add the items to this map in the > same way: for C++ get the fully qualified name and add the entry to the map > with the fully qualified name and an empty Declaration... I didn't realize that the solution would be this simple, conceptually. > Can you try this solution out and see if it fixes our issues? This does seem to work for one library but not another. My best guess would be that the solution works when dynamically linking to conflicting symbols, but not when the conflicting symbols are statically linked. Does that make sense? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [BUG?] Confusion between translation units?
> On Oct 26, 2015, at 12:45 PM, Ramkumar Ramachandra wrote: > > Greg, > > Greg Clayton wrote: >> Note that for C++ we get the fully qualified name and we pass in an empty >> Declaration() so they all will compare to the same thing. This would solve >> our current issue. We would also need to add the items to this map in the >> same way: for C++ get the fully qualified name and add the entry to the map >> with the fully qualified name and an empty Declaration... > > I didn't realize that the solution would be this simple, conceptually. > >> Can you try this solution out and see if it fixes our issues? > > This does seem to work for one library but not another. > > My best guess would be that the solution works when dynamically > linking to conflicting symbols, but not when the conflicting symbols > are statically linked. Does that make sense? Not really. If you can send me a concrete example of something that isn't working, it might help. When static linking occurs now we should have liba.dylib with llvm::foo::bar defined on bar.h line 12 in the DWARF with: ~/src/llvm/include/llvm/foo/bar.h:12 and another whose decl file and line is: /usr/local/include/llvm/include/llvm/foo/bar.h:12 The name that was being store was "bar" with the byte size and one of the two decl file and lines from above. Is this the static linking case you meant above when you stated "but not when the conflicting symbols are statically linked"? If so, our current fix would enter the type in with the name "llvm::foo::bar" and with an empty decl file and line. Then both cases from the above previously failing static linking case would work because they would avoid using the decl file + line to differentiate the two types. Does this make sense? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
