labath added a comment.
Thank you for implementing this. We've had code like this in android studio for
a long time, but it's definitely better doing it in lldb instead.
I'll give some more background so that Jim and anyone else looking at this can
understand what's going on. These files (I for
labath updated this revision to Diff 151484.
labath added a comment.
Fix a typo in netbsd code.
https://reviews.llvm.org/D47889
Files:
include/lldb/Core/Module.h
include/lldb/Host/freebsd/HostInfoFreeBSD.h
include/lldb/Host/linux/HostInfoLinux.h
include/lldb/Host/macosx/HostInfoMacOSX.h
labath created this revision.
labath added reviewers: zturner, jingham, davide.
Herald added a subscriber: mgorny.
The only reason python was used in the Host module was to compute the
python path. I resolve this the same way as https://reviews.llvm.org/D47384 did
for clang, moving
the path compu
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
I didn't remember we already did this in SBError... Sorry about that.
https://reviews.llvm.org/D48212
___
lldb-commits mailing list
lldb-comm
clayborg added inline comments.
Comment at: source/API/SBHostOS.cpp:48
+ case ePathTypePythonDir:
+fspec = ScriptInterpreterPython::GetPythonDir();
+break;
Why is this here instead of inside of "HostInfo::GetLLDBPath(path_type,
fspec);"? Does this mean
The internal api has no guarantees as to its stability.
On Fri, Jun 15, 2018 at 7:48 AM Greg Clayton via Phabricator <
revi...@reviews.llvm.org> wrote:
> clayborg added inline comments.
>
>
>
> Comment at: source/API/SBHostOS.cpp:48
> + case ePathTypePythonDir:
> +fspec = Scr
zturner added a subscriber: labath.
zturner added a comment.
The internal api has no guarantees as to its stability.
https://reviews.llvm.org/D48215
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/list
clayborg added a comment.
In https://reviews.llvm.org/D48215#1133695, @zturner wrote:
> The internal api has no guarantees as to its stability.
What do you mean by this? If we have an internal API that claims to give out
paths, it should give out paths. What am I missing here?
https://review
It can assert when we pass the python or clang directory enumeration. We
could also remove the values from the internal enumeration but keep them in
the public enumeration. However, we can’t be forced into providing a stable
internal api just because we must provide a stable public api.
On Fri, Jun
zturner added a comment.
It can assert when we pass the python or clang directory enumeration. We
could also remove the values from the internal enumeration but keep them in
the public enumeration. However, we can’t be forced into providing a stable
internal api just because we must provide a stab
labath added a comment.
Actually, my plan was to follow this up with a patch which removes usages of
that enumeration from the internal api altogether (basically do a
`s/GetLLDBPath(ePathTypeXXX/GetXXXPath`). That should make the internal api
nicer, and provide a clean separation between the in
labath added a comment.
(pressed return too soon)
Would that address your reservations about this idea?
https://reviews.llvm.org/D48215
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-co
clayborg added a comment.
It might be nice to start with the removal of HostInfo::GetLLDBPath(...) first
and fixing up all call sites that use that API to use the new internally
sanctioned versions. Then submit this patch?
https://reviews.llvm.org/D48215
clayborg added a comment.
In https://reviews.llvm.org/D48215#1133725, @labath wrote:
> (pressed return too soon)
>
> Would that address your reservations about this idea?
yeah, just don't like the idea of HostInfo::GetLLDBPath() being non functional.
https://reviews.llvm.org/D48215
___
labath planned changes to this revision.
labath added a comment.
Ok, I'll start with the other patch first.
https://reviews.llvm.org/D48215
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb
Thanks for the explanation!
Jim
> On Jun 15, 2018, at 2:35 AM, Pavel Labath via Phabricator
> wrote:
>
> labath added a comment.
>
> Thank you for implementing this. We've had code like this in android studio
> for a long time, but it's definitely better doing it in lldb instead.
>
> I'll
jingham added a subscriber: clayborg.
jingham added a comment.
Thanks for the explanation!
Jim
https://reviews.llvm.org/D48177
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
xiaobai updated this revision to Diff 151543.
xiaobai added a comment.
Pavel's suggestions.
https://reviews.llvm.org/D48060
Files:
CMakeLists.txt
cmake/modules/AddLLDB.cmake
cmake/modules/LLDBFramework.cmake
source/API/CMakeLists.txt
tools/driver/CMakeLists.txt
Index: tools/driver/CM
xiaobai added a comment.
I think this is in a pretty good state. I built LLDB.framework with xcodebuild
and compared it. There are still some discrepancies but this brings us a step
closer to a final working solution.
Comment at: cmake/modules/LLDBFramework.cmake:45
+
+ add_
Author: apolyakov
Date: Fri Jun 15 13:20:39 2018
New Revision: 334860
URL: http://llvm.org/viewvc/llvm-project?rev=334860&view=rev
Log:
Revert "[lldb-mi] Add overload method for setting an error"
Summary: This reverts commit r334245 because it duplicates
functionality of Status::AsCString used in
This revision was automatically updated to reflect the committed changes.
Closed by commit rL334860: Revert "[lldb-mi] Add overload method for
setting an error" (authored by apolyakov, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D48
labath added a comment.
This is looking very good, I just have one more quick question. I am wondering
whether we couldn't simplify this dependency management a tad bit more. Would
the thing I'm proposing below work for you?
Comment at: CMakeLists.txt:147-153
+ if (LLDB_CAN
Author: friss
Date: Fri Jun 15 13:36:03 2018
New Revision: 334861
URL: http://llvm.org/viewvc/llvm-project?rev=334861&view=rev
Log:
Fix TestExec after r334783
The second makefile that was added has implicit rules which meant
that secondprog.cpp would be built once into a secondprog binary,
but it
apolyakov added a comment.
If you look at `bool CMICmdCmdExecContinue::Execute()`, you'll see that there
are cases in which we need a flexible way to finish MI command(specific action
in error case for example). We have a few options: not to add such an utility
function, add and use it in simpl
xiaobai added a comment.
xiaobai added inline comments.
Comment at: cmake/modules/AddLLDB.cmake:102-104
if(LLDB_BUILD_FRAMEWORK)
if(ARG_INCLUDE_IN_FRAMEWORK)
+ add_dependencies(lldb-framework ${name})
labath wrote:
> If you reorder this slightly, the
kubamracek added a comment.
In https://reviews.llvm.org/D44603#1133149, @jingham wrote:
> This is going as I imagined it should, looks great!
> We probably want to turn this on by default for "frame var" or no one will
> ever discover it. The IDE folks can decide on their own what to do from t
Author: jmolenda
Date: Fri Jun 15 16:29:32 2018
New Revision: 334872
URL: http://llvm.org/viewvc/llvm-project?rev=334872&view=rev
Log:
Sort the files in the PBXBuildFile and PBXFileReference
sections of lldb's xcode project file to reduce automerger
issues with the github swift repository of lldb
Author: jmolenda
Date: Fri Jun 15 16:32:37 2018
New Revision: 334873
URL: http://llvm.org/viewvc/llvm-project?rev=334873&view=rev
Log:
Sort the files in the PBXBuildFile and PBXFileReference sections
of debugserver's xcode project file to reduce automerger issues
with the github swift repository o
xiaobai updated this revision to Diff 151598.
xiaobai added a comment.
Labath's suggestion
https://reviews.llvm.org/D48060
Files:
CMakeLists.txt
cmake/modules/AddLLDB.cmake
cmake/modules/LLDBFramework.cmake
source/API/CMakeLists.txt
tools/argdumper/CMakeLists.txt
tools/darwin-debug/
29 matches
Mail list logo
