Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

[Pavel Labath via lldb-dev]

Instead of "image search-paths add" you should be able to do a
"settings append target.exec-search-paths /your/sysroot". That one
should not require a running target or anything like that.

However, I agree that it would be nice for the platform sysroot to
work out of the box. Particularly, as we can then use it to do other
nice things (e.g. prevent matching of files in the main filesystem, so
we can avoid the ld-linux-x86-64.so.2 problem you encountered).

For the patch, can you create a review on the LLVM phabricator
? We can discuss the approach
there.

On Fri, 20 Jul 2018 at 23:55, Eugene Birukov via lldb-dev
 wrote:
>
> I have a small fix – pass platform sysroot to ModuleList::GetSharedModule. 
> The fix works for me.
>
>
>
> What should I do to get it reviewed?
>
>
>
> Thanks,
>
> Eugene
>
>
>
> diff --git a/include/lldb/Core/ModuleList.h b/include/lldb/Core/ModuleList.h
>
> index 4b637c9..3214291 100644
>
> --- a/include/lldb/Core/ModuleList.h
>
> +++ b/include/lldb/Core/ModuleList.h
>
> @@ -541,7 +541,8 @@ public:
>
>  const FileSpecList *module_search_paths_ptr,
>
>  lldb::ModuleSP *old_module_sp_ptr,
>
>  bool *did_create_ptr,
>
> -bool always_create = false);
>
> +bool always_create = false,
>
> +const char* sysroot = nullptr);
>
>
>
>static bool RemoveSharedModule(lldb::ModuleSP &module_sp);
>
>
>
> diff --git a/source/Core/ModuleList.cpp b/source/Core/ModuleList.cpp
>
> index 3970052..f2db3bb 100644
>
> --- a/source/Core/ModuleList.cpp
>
> +++ b/source/Core/ModuleList.cpp
>
> @@ -707,7 +707,11 @@ Status ModuleList::GetSharedModule(const ModuleSpec 
> &module_spec,
>
> ModuleSP &module_sp,
>
> const FileSpecList 
> *module_search_paths_ptr,
>
> ModuleSP *old_module_sp_ptr,
>
> -   bool *did_create_ptr, bool always_create) 
> {
>
> +   bool *did_create_ptr, bool always_create,
>
> +   const char* sysroot) {
>
> +  // Make sure no one else can try and get or create a module while this
>
> +  // function is actively working on it by doing an extra lock on the
>
> +  // global mutex list.
>
>ModuleList &shared_module_list = GetSharedModuleList();
>
>std::lock_guard guard(
>
>shared_module_list.m_modules_mutex);
>
> @@ -726,9 +730,6 @@ Status ModuleList::GetSharedModule(const ModuleSpec 
> &module_spec,
>
>const FileSpec &module_file_spec = module_spec.GetFileSpec();
>
>const ArchSpec &arch = module_spec.GetArchitecture();
>
>
>
> -  // Make sure no one else can try and get or create a module while this
>
> -  // function is actively working on it by doing an extra lock on the
>
> -  // global mutex list.
>
>if (!always_create) {
>
>  ModuleList matching_module_list;
>
>  const size_t num_matching_modules =
>
> @@ -762,7 +763,11 @@ Status ModuleList::GetSharedModule(const ModuleSpec 
> &module_spec,
>
>if (module_sp)
>
>  return error;
>
>
>
> -  module_sp.reset(new Module(module_spec));
>
> +  auto resolved_module_spec(module_spec);
>
> +  if (sysroot != nullptr)
>
> +resolved_module_spec.GetFileSpec().PrependPathComponent(sysroot);
>
> +
>
> +  module_sp.reset(new Module(resolved_module_spec));
>
>// Make sure there are a module and an object file since we can specify
>
>// a valid file path with an architecture that might not be in that file.
>
>// By getting the object file we can guarantee that the architecture 
> matches
>
> diff --git a/source/Target/Platform.cpp b/source/Target/Platform.cpp
>
> index 5d60bb7..19161cc 100644
>
> --- a/source/Target/Platform.cpp
>
> +++ b/source/Target/Platform.cpp
>
> @@ -225,13 +225,14 @@ Status Platform::GetSharedModule(const ModuleSpec 
> &module_spec,
>
>if (IsHost())
>
>  return ModuleList::GetSharedModule(
>
>  module_spec, module_sp, module_search_paths_ptr, old_module_sp_ptr,
>
> -did_create_ptr, false);
>
> +did_create_ptr, false, m_sdk_sysroot.AsCString());
>
>
>
>return GetRemoteSharedModule(module_spec, process, module_sp,
>
> [&](const ModuleSpec &spec) {
>
>   Status error = ModuleList::GetSharedModule(
>
>   spec, module_sp, 
> module_search_paths_ptr,
>
> - old_module_sp_ptr, did_create_ptr, 
> false);
>
> + old_module_sp_ptr, did_create_ptr, 
> false,
>
> + m_sdk_sysroot.AsCString());
>
>   if (error.Success() && module_sp)
>
> module_sp->SetPlatf

Re: [lldb-dev] MI Handle events.

[Pavel Labath via lldb-dev]

Well, judging by this snippet
=
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp-  case lldb::eStateStopped:
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp-pEventType =
"eStateStopped";
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp-bOk =
HandleProcessEventStateStopped(vEvent, bShouldB
rk);
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp-if (bShouldBrk)
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp-  break;
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp-LLVM_FALLTHROUGH;
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp-  case lldb::eStateCrashed:
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp-  case lldb::eStateSuspended:
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp-pEventType =
"eStateSuspended";
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp:bOk =
HandleProcessEventStateSuspended(vEvent);
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp-break;
=

it looks like HandleProcessEventStateSuspended can be called in three cases:
1) HandleProcessEventStateStopped sets bShouldBrk to false
2) we get an eStateSuspended event
3) we get an eStateCrashed event

As I said earlier I don't believe (2) can ever happen. I haven't
looked at what can cause (1), but I am sure you can get (3) on a
Mac(*) if your process does a null pointer dereference or a similar
"crashing" action. Is there any test like that in the lldb-mi test
suite?

(*) On linux we just report this as a regular eStateStopped event with
stop_reason = SIGSEGV.

On Mon, 23 Jul 2018 at 09:38, Adrian Prantl  wrote:
>
> Have you tried my other suggestion; doing an actual debug session with an 
> lldb-mi client (emacs/vim/vs code/eclipse)? Of that doesn't work,  I'm afraid 
> you may have to do some detective work here to figure out how to add test 
> coverage for this code path. I ssume that you already tried to create a 
> synthetic test that suspends a process and then queries the status through 
> the MI interface?
>
> -- adrian
>
> On Jul 19, 2018, at 10:14 PM, Александр Поляков  
> wrote:
>
> I've tried to put an assert into HandleProcessEventStateSuspended, but there 
> wasn't a testcase triggering it. So, my question is still actual, any help 
> will be really appreciate.
>
> пн, 16 июл. 2018 г. в 13:56, Pavel Labath :
>>
>> The eStateSuspended state is used for threads (you can set it via
>> SBThread::Suspend/Resume). It controls whether a "continue" operation
>> on the process will run the thread or not.
>>
>> I am not sure if you can ever see that state on the process itself.
>>
>>
>> On Sat, 14 Jul 2018 at 15:39, Adrian Prantl via lldb-dev
>>  wrote:
>> >
>> >
>> >
>> > > On Jul 13, 2018, at 10:59 PM, Александр Поляков  
>> > > wrote:
>> > >
>> > > Hi lldb-dev,
>> > >
>> > > I'm looking at re-implementing of 
>> > > CMICmnLLDBDebugHandleEvents::HandleProcessEventStateSuspended to get rid 
>> > > of HandleCommand("process status") hack and use SB API instead. To check 
>> > > my changes I need to get HandleProcessEventStateSuspended called, so 
>> > > could someone help me with a sequence of lldb-mi commands which will 
>> > > call HandleProcessEventStateSuspended.
>> >
>> > Other than reading through the code and manually tracing a sequence where 
>> > this function gets called, one simple trick you can try is to put an 
>> > assert(false) into HandleProcessEventStateSuspended, run the testsuite (or 
>> > perform an lldb-mi debug session) and look for a testacase that triggers 
>> > the new assertion.
>> >
>> > -- adrian
>> >
>> > >
>> > > Thanks in advance.
>> > >
>> > > --
>> > > Alexander
>> >
>> > ___
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
> --
> Alexander
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 38233] LLDB build fails when done with GCC 8.1 against Python 3

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=38233

lab...@google.com changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |lab...@google.com

--- Comment #3 from lab...@google.com ---
Judging by  the signature of that
function changed in python 3.7. Are you using python>=3.7 by any chance?

Can you check whether the attached patch fixed the problem for you?

-- 
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

[lldb-dev] ClangASTContext::AddMethodToObjCObjectType constructs ParmVarDecl without identifier

[Nat! via lldb-dev]

Hi

So my real main problem is that I want to run an expression to output 
the value of an Objective-C parameter. e.g. `- (void) foo:(id) a`. I 
want to print `a` when I am stopped in `foo`.


This isn't working for me - technically, I believe - because, in 
`ClangASTContext::AddMethodToObjCObjectType` the name of the parameter 
is omitted in the ParmVarDecl, specifically commented as "anonymous"


```
params.push_back(clang::ParmVarDecl::Create(
  *ast, objc_method_decl, clang::SourceLocation(),
  clang::SourceLocation(),
  nullptr, // anonymous
  method_function_prototype->getParamType(param_index), nullptr,
  clang::SC_Auto, nullptr));
```

I don't really see, how and when this information is added at a later 
stage, but I assune it is somehow. (Not by my ObjC Runtime plugin though)


What I find curious is that the names of the ParmVarDecls have already 
been determined in `DWARFFastParserClang::ParseChildParameters` and are 
saved into `function_param_decls`. That is just ahead of the only call 
to `AddMethodToObjCObjectType` in lldb. But that information isn't 
passed. Is there a reason why not ?


Ciao
   Nat!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Process launch view duplication

[Dávid Bolvanský via lldb-dev]

Hello,

Our slightly modified LLDB based on v6.0 with custom platform and process
has a strange problem during process launch. We see the debugger view
twice. After stepping over, we see it correctly - just once. Does anybody
know where the problem could be?

Process, platform, thread, event logs: https://pastebin.com/3Ecns4W5

(lldb) target create "/home/davidbolvansky/Plocha/file.xexe"
Current executable set to '/home/davidbolvansky/Plocha/file.xexe'.
(lldb) b main
Breakpoint 1: where = file.xexe`main + 32 at bitcnt.c:76, address =
0x01ec
(lldb) r
info: dynamic port 45999
info: Waiting for a client...
Process 1 launched: '/home/davidbolvansky/Plocha/file.xexe'.
Process 1 stopped
* thread #1, stop reason = breakpoint 1.1
frame #0: 0x01ec file.xexe`main(argc=1, argv=0x08c0) at
bitcnt.c:76
   73 long i, j;
   74 unsigned long count;
   75
-> 76 for (i = 0; i < BENCHMARK_RUNS; i++)
   77 {
   78   count = 0;
   79   for (j = 0; j < DATA_TAB_SIZE; j++)
Process 1 stopped
* thread #1, stop reason = breakpoint 1.1
frame #0: 0x01ec file.xexe`main(argc=1, argv=0x08c0) at
bitcnt.c:76
   73 long i, j;
   74 unsigned long count;
   75
-> 76 for (i = 0; i < BENCHMARK_RUNS; i++)
   77 {
   78   count = 0;
   79   for (j = 0; j < DATA_TAB_SIZE; j++)
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Cannot install from source

[nu quaquaraqua via lldb-dev]

just a quick update, I moved on by commenting out the lines 40-42 in
build/tools/lldb/scripts/cmake_install.cmake:

if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT
CMAKE_INSTALL_COMPONENT)
  file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/lib" TYPE DIRECTORY
FILES "/opt/llvm/build/lib/python2.7")
endif()

Quack

On 18 July 2018 at 23:25, Quaquaraquà  wrote:

> the target is built fine, with no warnings or other related messages. I
> tried to dig a bit, but I wasn't able to understand how it is supposed to
> be built . The only refs I've found are inside lldbUtility, protected by a
> guard on LLVM_BUILD_STATIC which does seem to be defined nowhere, and
> scripts/install_custom_python.py which seems to be mostly concerning
> windows.
>
> Quack
>
> On 18/07/18 18:39, Ted Woodward wrote:
>
> It should be built by the “lldb” target. What does that do?
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org
> ] *On Behalf Of *Quaquaraquà via lldb-dev
> *Sent:* Wednesday, July 18, 2018 11:29 AM
> *To:* lldb-dev@lists.llvm.org
> *Subject:* Re: [lldb-dev] Cannot install from source
>
>
>
> Indeed that folder is not present. Python 2.7 is installed and it is the
> default version of the system, I'm not changing its setting in the build.
>
> On 18/07/18 18:19, Ted Woodward wrote:
>
> When I do a build on Linux, in /lib I see a directory called
> python2.7, with a subdirectory site-packages. Do you not see this?
>
>
>
> Are you building with a different python version than 2.7.x?
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org
> ] *On Behalf Of *nu quaquaraqua via
> lldb-dev
> *Sent:* Wednesday, July 18, 2018 8:17 AM
> *To:* lldb-dev@lists.llvm.org
> *Subject:* [lldb-dev] Cannot install from source
>
>
>
> Dear folks,
>
>
>
> I am trying to build & install LLVM, Clang and LLDB from source. Now the
> build completes fine, while the target `install' fails:
>
>
>
> -- Up-to-date: /opt/llvm/6.0.1/include/lldb/Host/Config.h
>
> CMake Error at tools/lldb/scripts/cmake_install.cmake:41 (file):
>
>   file INSTALL cannot find "/opt/llvm/build/lib/python2.7".
>
> Call Stack (most recent call first):
>
>   tools/lldb/cmake_install.cmake:51 (include)
>
>   tools/cmake_install.cmake:49 (include)
>
>   cmake_install.cmake:65 (include)
>
>
>
>
>
> make: *** [Makefile:140: install] Error 1
>
>
>
>
>
> I am on branch `release 6.0', out of source build, all the defaults with
> the exception of the build type set to Release, custom prefix path, and
> target to build X86. The system is a Linux Fedora v28.
>
>
>
> Suggestions on how to move on? :-)
>
> Yours,
>
> Quack
>
>
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

[Eugene Birukov via lldb-dev]

I believe using search path is not the right approach when opening a core dump. 
We do not need to search for modules: we know exactly what has been loaded from 
where when the application crashed. The only problem is that the machine was 
different, so we need to prepend sysroot and get them form there. Scanning 
search path chain and grabbing arbitrary files that happen to have matching 
name would confuse the debugger.

If nobody objects, I'll prepare this change in phabricator.

-Original Message-
From: Pavel Labath  
Sent: Monday, July 23, 2018 2:42 AM
To: Eugene Birukov 
Cc: LLDB 
Subject: Re: [lldb-dev] LLDB does not respect platform sysroot when loading 
core on Linux

Instead of "image search-paths add" you should be able to do a "settings append 
target.exec-search-paths /your/sysroot". That one should not require a running 
target or anything like that.

However, I agree that it would be nice for the platform sysroot to work out of 
the box. Particularly, as we can then use it to do other nice things (e.g. 
prevent matching of files in the main filesystem, so we can avoid the 
ld-linux-x86-64.so.2 problem you encountered).

For the patch, can you create a review on the LLVM phabricator 
?
 We can discuss the approach there.

On Fri, 20 Jul 2018 at 23:55, Eugene Birukov via lldb-dev 
 wrote:
>
> I have a small fix – pass platform sysroot to ModuleList::GetSharedModule. 
> The fix works for me.
>
>
>
> What should I do to get it reviewed?
>
>
>
> Thanks,
>
> Eugene
>
>
>
> diff --git a/include/lldb/Core/ModuleList.h 
> b/include/lldb/Core/ModuleList.h
>
> index 4b637c9..3214291 100644
>
> --- a/include/lldb/Core/ModuleList.h
>
> +++ b/include/lldb/Core/ModuleList.h
>
> @@ -541,7 +541,8 @@ public:
>
>  const FileSpecList 
> *module_search_paths_ptr,
>
>  lldb::ModuleSP *old_module_sp_ptr,
>
>  bool *did_create_ptr,
>
> -bool always_create = false);
>
> +bool always_create = false,
>
> +const char* sysroot = nullptr);
>
>
>
>static bool RemoveSharedModule(lldb::ModuleSP &module_sp);
>
>
>
> diff --git a/source/Core/ModuleList.cpp b/source/Core/ModuleList.cpp
>
> index 3970052..f2db3bb 100644
>
> --- a/source/Core/ModuleList.cpp
>
> +++ b/source/Core/ModuleList.cpp
>
> @@ -707,7 +707,11 @@ Status ModuleList::GetSharedModule(const 
> ModuleSpec &module_spec,
>
> ModuleSP &module_sp,
>
> const FileSpecList 
> *module_search_paths_ptr,
>
> ModuleSP *old_module_sp_ptr,
>
> -   bool *did_create_ptr, bool always_create) 
> {
>
> +   bool *did_create_ptr, bool 
> + always_create,
>
> +   const char* sysroot) {
>
> +  // Make sure no one else can try and get or create a module while 
> + this
>
> +  // function is actively working on it by doing an extra lock on the
>
> +  // global mutex list.
>
>ModuleList &shared_module_list = GetSharedModuleList();
>
>std::lock_guard guard(
>
>shared_module_list.m_modules_mutex);
>
> @@ -726,9 +730,6 @@ Status ModuleList::GetSharedModule(const 
> ModuleSpec &module_spec,
>
>const FileSpec &module_file_spec = module_spec.GetFileSpec();
>
>const ArchSpec &arch = module_spec.GetArchitecture();
>
>
>
> -  // Make sure no one else can try and get or create a module while 
> this
>
> -  // function is actively working on it by doing an extra lock on the
>
> -  // global mutex list.
>
>if (!always_create) {
>
>  ModuleList matching_module_list;
>
>  const size_t num_matching_modules =
>
> @@ -762,7 +763,11 @@ Status ModuleList::GetSharedModule(const 
> ModuleSpec &module_spec,
>
>if (module_sp)
>
>  return error;
>
>
>
> -  module_sp.reset(new Module(module_spec));
>
> +  auto resolved_module_spec(module_spec);
>
> +  if (sysroot != nullptr)
>
> +resolved_module_spec.GetFileSpec().PrependPathComponent(sysroot);
>
> +
>
> +  module_sp.reset(new Module(resolved_module_spec));
>
>// Make sure there are a module and an object file since we can 
> specify
>
>// a valid file path with an architecture that might not be in that file.
>
>// By getting the object file we can guarantee that the 
> architecture matches
>
> diff --git a/source/Target/Platform.cpp b/source/Target/Platform.cpp
>
> index 5d60bb7..19161cc 100644
>
> --- a/source/Target/Platform.cpp
>
> +++ b/source/Target/Platform.cpp
>
> @@ -225,13 +225,14 @@ Status Platfo

Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

[Greg Clayton via lldb-dev]

If --sysroot is supplied, then it should just work as you say. The platform 
code will be asked to locate the file and the remote-linux platform is failing 
here and needs to be fixed.

Greg


> On Jul 23, 2018, at 2:42 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> Instead of "image search-paths add" you should be able to do a
> "settings append target.exec-search-paths /your/sysroot". That one
> should not require a running target or anything like that.
> 
> However, I agree that it would be nice for the platform sysroot to
> work out of the box. Particularly, as we can then use it to do other
> nice things (e.g. prevent matching of files in the main filesystem, so
> we can avoid the ld-linux-x86-64.so.2 problem you encountered).
> 
> For the patch, can you create a review on the LLVM phabricator
> ? We can discuss the approach
> there.
> 
> On Fri, 20 Jul 2018 at 23:55, Eugene Birukov via lldb-dev
>  wrote:
>> 
>> I have a small fix – pass platform sysroot to ModuleList::GetSharedModule. 
>> The fix works for me.
>> 
>> 
>> 
>> What should I do to get it reviewed?
>> 
>> 
>> 
>> Thanks,
>> 
>> Eugene
>> 
>> 
>> 
>> diff --git a/include/lldb/Core/ModuleList.h b/include/lldb/Core/ModuleList.h
>> 
>> index 4b637c9..3214291 100644
>> 
>> --- a/include/lldb/Core/ModuleList.h
>> 
>> +++ b/include/lldb/Core/ModuleList.h
>> 
>> @@ -541,7 +541,8 @@ public:
>> 
>> const FileSpecList *module_search_paths_ptr,
>> 
>> lldb::ModuleSP *old_module_sp_ptr,
>> 
>> bool *did_create_ptr,
>> 
>> -bool always_create = false);
>> 
>> +bool always_create = false,
>> 
>> +const char* sysroot = nullptr);
>> 
>> 
>> 
>>   static bool RemoveSharedModule(lldb::ModuleSP &module_sp);
>> 
>> 
>> 
>> diff --git a/source/Core/ModuleList.cpp b/source/Core/ModuleList.cpp
>> 
>> index 3970052..f2db3bb 100644
>> 
>> --- a/source/Core/ModuleList.cpp
>> 
>> +++ b/source/Core/ModuleList.cpp
>> 
>> @@ -707,7 +707,11 @@ Status ModuleList::GetSharedModule(const ModuleSpec 
>> &module_spec,
>> 
>>ModuleSP &module_sp,
>> 
>>const FileSpecList 
>> *module_search_paths_ptr,
>> 
>>ModuleSP *old_module_sp_ptr,
>> 
>> -   bool *did_create_ptr, bool 
>> always_create) {
>> 
>> +   bool *did_create_ptr, bool always_create,
>> 
>> +   const char* sysroot) {
>> 
>> +  // Make sure no one else can try and get or create a module while this
>> 
>> +  // function is actively working on it by doing an extra lock on the
>> 
>> +  // global mutex list.
>> 
>>   ModuleList &shared_module_list = GetSharedModuleList();
>> 
>>   std::lock_guard guard(
>> 
>>   shared_module_list.m_modules_mutex);
>> 
>> @@ -726,9 +730,6 @@ Status ModuleList::GetSharedModule(const ModuleSpec 
>> &module_spec,
>> 
>>   const FileSpec &module_file_spec = module_spec.GetFileSpec();
>> 
>>   const ArchSpec &arch = module_spec.GetArchitecture();
>> 
>> 
>> 
>> -  // Make sure no one else can try and get or create a module while this
>> 
>> -  // function is actively working on it by doing an extra lock on the
>> 
>> -  // global mutex list.
>> 
>>   if (!always_create) {
>> 
>> ModuleList matching_module_list;
>> 
>> const size_t num_matching_modules =
>> 
>> @@ -762,7 +763,11 @@ Status ModuleList::GetSharedModule(const ModuleSpec 
>> &module_spec,
>> 
>>   if (module_sp)
>> 
>> return error;
>> 
>> 
>> 
>> -  module_sp.reset(new Module(module_spec));
>> 
>> +  auto resolved_module_spec(module_spec);
>> 
>> +  if (sysroot != nullptr)
>> 
>> +resolved_module_spec.GetFileSpec().PrependPathComponent(sysroot);
>> 
>> +
>> 
>> +  module_sp.reset(new Module(resolved_module_spec));
>> 
>>   // Make sure there are a module and an object file since we can specify
>> 
>>   // a valid file path with an architecture that might not be in that file.
>> 
>>   // By getting the object file we can guarantee that the architecture 
>> matches
>> 
>> diff --git a/source/Target/Platform.cpp b/source/Target/Platform.cpp
>> 
>> index 5d60bb7..19161cc 100644
>> 
>> --- a/source/Target/Platform.cpp
>> 
>> +++ b/source/Target/Platform.cpp
>> 
>> @@ -225,13 +225,14 @@ Status Platform::GetSharedModule(const ModuleSpec 
>> &module_spec,
>> 
>>   if (IsHost())
>> 
>> return ModuleList::GetSharedModule(
>> 
>> module_spec, module_sp, module_search_paths_ptr, old_module_sp_ptr,
>> 
>> -did_create_ptr, false);
>> 
>> +did_create_ptr, false, m_sdk_sysroot.AsCString());
>> 
>> 
>> 
>>   return GetRemoteSharedModule(module_spec, process, module_sp,
>> 
>>[&](const ModuleSpec &spec) {
>> 
>>

[lldb-dev] Xcode project creates too many diffs if I just add or remove a file...

[Greg Clayton via lldb-dev]

Anyone know if something has happened to the Xcode project file? Did someone 
sort or try to manually do something to the Xcode project? If I add or remove a 
file, then I end up with 1000s of diffs...

Greg

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Xcode project creates too many diffs if I just add or remove a file...

[Raphael “Teemperor” Isemann via lldb-dev]

See Jason’s email from two weeks ago:

> I didn't intend for it, but when you add a file to the xcode project file, 
> Xcode will reorder all the currently-sorted files and we'll get all the same 
> merge conflicts we've had for the past couple years again.
> We could either back out my sorting of the project files (and continue to 
> have constant merge conflicts like always) or we can sort the xcode project 
> file every time we have to add something to it.  That's what we're doing.
> scripts/sort-pbxproj.rb is the script I threw together to do this.  Run it in 
> the lldb.xcodeproj directory and it will output a new project file on stdout. 
>  Not the most friendly UI, I can go back and revisit that later.
> J

> On Jul 23, 2018, at 3:04 PM, Greg Clayton via lldb-dev 
>  wrote:
> 
> Anyone know if something has happened to the Xcode project file? Did someone 
> sort or try to manually do something to the Xcode project? If I add or remove 
> a file, then I end up with 1000s of diffs...
> 
> Greg
> 
> ___
> 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] Xcode project creates too many diffs if I just add or remove a file...

[Greg Clayton via lldb-dev]

The script will nuke the project.pbxproj file you do:

../scripts/sort-pbxproj.rb > project.pbxproj

So it seems you must do:

../scripts/sort-pbxproj.rb > project.pbxproj2
mv project.pbxproj2 project.pbxproj

Is this expected??

> On Jul 23, 2018, at 3:07 PM, Raphael “Teemperor” Isemann 
>  wrote:
> 
> See Jason’s email from two weeks ago:
> 
>> I didn't intend for it, but when you add a file to the xcode project file, 
>> Xcode will reorder all the currently-sorted files and we'll get all the same 
>> merge conflicts we've had for the past couple years again.
>> We could either back out my sorting of the project files (and continue to 
>> have constant merge conflicts like always) or we can sort the xcode project 
>> file every time we have to add something to it.  That's what we're doing.
>> scripts/sort-pbxproj.rb is the script I threw together to do this.  Run it 
>> in the lldb.xcodeproj directory and it will output a new project file on 
>> stdout.  Not the most friendly UI, I can go back and revisit that later.
>> J
> 
>> On Jul 23, 2018, at 3:04 PM, Greg Clayton via lldb-dev 
>>  wrote:
>> 
>> Anyone know if something has happened to the Xcode project file? Did someone 
>> sort or try to manually do something to the Xcode project? If I add or 
>> remove a file, then I end up with 1000s of diffs...
>> 
>> Greg
>> 
>> ___
>> 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] Xcode project creates too many diffs if I just add or remove a file...

[Raphael “Teemperor” Isemann via lldb-dev]

That’s just how IO redirection works in sh. But I agree that the expected 
default behavior is to just overwrite the file without having to redirect any 
streams/tmp files (+ Jason because he probably can easily fix this).

- Raphael

> On Jul 23, 2018, at 3:24 PM, Greg Clayton  wrote:
> 
> The script will nuke the project.pbxproj file you do:
> 
> ../scripts/sort-pbxproj.rb > project.pbxproj
> 
> So it seems you must do:
> 
> ../scripts/sort-pbxproj.rb > project.pbxproj2
> mv project.pbxproj2 project.pbxproj
> 
> Is this expected??
> 
>> On Jul 23, 2018, at 3:07 PM, Raphael “Teemperor” Isemann 
>>  wrote:
>> 
>> See Jason’s email from two weeks ago:
>> 
>>> I didn't intend for it, but when you add a file to the xcode project file, 
>>> Xcode will reorder all the currently-sorted files and we'll get all the 
>>> same merge conflicts we've had for the past couple years again.
>>> We could either back out my sorting of the project files (and continue to 
>>> have constant merge conflicts like always) or we can sort the xcode project 
>>> file every time we have to add something to it.  That's what we're doing.
>>> scripts/sort-pbxproj.rb is the script I threw together to do this.  Run it 
>>> in the lldb.xcodeproj directory and it will output a new project file on 
>>> stdout.  Not the most friendly UI, I can go back and revisit that later.
>>> J
>> 
>>> On Jul 23, 2018, at 3:04 PM, Greg Clayton via lldb-dev 
>>>  wrote:
>>> 
>>> Anyone know if something has happened to the Xcode project file? Did 
>>> someone sort or try to manually do something to the Xcode project? If I add 
>>> or remove a file, then I end up with 1000s of diffs...
>>> 
>>> Greg
>>> 
>>> ___
>>> 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] Xcode project creates too many diffs if I just add or remove a file...

[Jason Molenda via lldb-dev]

Yeah, I wrote the script to accept stdin or a filename argument, and print its 
results.  I'll fix it to hardcode looking for lldb.xcodeproj/project.pbxproj or 
project.pbxproj in cwd and update it in place.


> On Jul 23, 2018, at 3:37 PM, Raphael “Teemperor” Isemann 
>  wrote:
> 
> That’s just how IO redirection works in sh. But I agree that the expected 
> default behavior is to just overwrite the file without having to redirect any 
> streams/tmp files (+ Jason because he probably can easily fix this).
> 
> - Raphael
> 
>> On Jul 23, 2018, at 3:24 PM, Greg Clayton  wrote:
>> 
>> The script will nuke the project.pbxproj file you do:
>> 
>> ../scripts/sort-pbxproj.rb > project.pbxproj
>> 
>> So it seems you must do:
>> 
>> ../scripts/sort-pbxproj.rb > project.pbxproj2
>> mv project.pbxproj2 project.pbxproj
>> 
>> Is this expected??
>> 
>>> On Jul 23, 2018, at 3:07 PM, Raphael “Teemperor” Isemann 
>>>  wrote:
>>> 
>>> See Jason’s email from two weeks ago:
>>> 
 I didn't intend for it, but when you add a file to the xcode project file, 
 Xcode will reorder all the currently-sorted files and we'll get all the 
 same merge conflicts we've had for the past couple years again.
 We could either back out my sorting of the project files (and continue to 
 have constant merge conflicts like always) or we can sort the xcode 
 project file every time we have to add something to it.  That's what we're 
 doing.
 scripts/sort-pbxproj.rb is the script I threw together to do this.  Run it 
 in the lldb.xcodeproj directory and it will output a new project file on 
 stdout.  Not the most friendly UI, I can go back and revisit that later.
 J
>>> 
 On Jul 23, 2018, at 3:04 PM, Greg Clayton via lldb-dev 
  wrote:
 
 Anyone know if something has happened to the Xcode project file? Did 
 someone sort or try to manually do something to the Xcode project? If I 
 add or remove a file, then I end up with 1000s of diffs...
 
 Greg
 
 ___
 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