date:20191028

[Lldb-commits] [PATCH] D69488: [LLDB][Python] fix another fflush issue on NetBSD

2019-10-28 Thread Lawrence D'Anna via Phabricator via lldb-commits

lawrence_danna updated this revision to Diff 226618.
lawrence_danna added a comment.

protect python from being exposed to C++ reference borrowing semantics


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69488/new/

https://reviews.llvm.org/D69488

Files:
  lldb/include/lldb/Host/File.h
  lldb/packages/Python/lldbsuite/test/python_api/file_handle/TestFileHandle.py
  lldb/source/Host/common/File.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h

Index: lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
===
--- lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
+++ lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
@@ -189,6 +189,14 @@
  "key not in dict");
 }
 
+#if PY_MAJOR_VERSION < 3
+// The python 2 API declares some arguments as char* that should
+// be const char *, but it doesn't actually modify them.
+inline char *py2_const_cast(const char *s) { return const_cast(s); }
+#else
+inline const char *py2_const_cast(const char *s) { return s; }
+#endif
+
 enum class PyInitialValue { Invalid, Empty };
 
 template  struct PythonFormat;
@@ -309,16 +317,6 @@
 
   StructuredData::ObjectSP CreateStructuredObject() const;
 
-protected:
-
-#if PY_MAJOR_VERSION < 3
-  // The python 2 API declares some arguments as char* that should
-  // be const char *, but it doesn't actually modify them.
-  static char *py2_const_cast(const char *s) { return const_cast(s); }
-#else
-  static const char *py2_const_cast(const char *s) { return s; }
-#endif
-
 public:
   template 
   llvm::Expected CallMethod(const char *name,
Index: lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
@@ -1502,12 +1502,28 @@
   file_obj = PyFile_FromFd(file.GetDescriptor(), nullptr, mode, -1, nullptr,
"ignore", nullptr, 0);
 #else
-  // Read through the Python source, doesn't seem to modify these strings
-  char *cmode = const_cast(mode);
-  // We pass ::flush instead of ::fclose here so we borrow the FILE* --
-  // the lldb_private::File still owns it.
-  file_obj =
-  PyFile_FromFile(file.GetStream(), const_cast(""), cmode, ::fflush);
+  // It's more or less safe to let a python program borrow a file descriptor.
+  // If they let it dangle and then use it, they'll probably get an exception.
+  // The worst that can happen is they'll wind up doing IO on the wrong
+  // descriptor.   But it would be very unsafe to let a python program borrow
+  // a FILE*.   They could actually crash the program just by keeping a
+  // reference to it around.Since in python 2 we must have a FILE* and
+  // not a descriptor, we dup the descriptor and fdopen a new FILE* to it
+  // so python can have something it can own safely.
+  auto opts = File::GetOptionsFromMode(mode);
+  if (!opts)
+return opts.takeError();
+  int fd = file.GetDescriptor();
+  if (!File::DescriptorIsValid(fd))
+return llvm::createStringError(llvm::inconvertibleErrorCode(),
+   "File has no file descriptor");
+  NativeFile dupfile(fd, opts.get(), false);
+  FILE *stream = NativeFile::ReleaseFILE(std::move(dupfile));
+  if (!stream)
+return llvm::createStringError(llvm::inconvertibleErrorCode(),
+   "could not create FILE* stream");
+  file_obj = PyFile_FromFile(stream, py2_const_cast(""), py2_const_cast(mode),
+ ::fclose);
 #endif
 
   if (!file_obj)
Index: lldb/source/Host/common/File.cpp
===
--- lldb/source/Host/common/File.cpp
+++ lldb/source/Host/common/File.cpp
@@ -304,13 +304,25 @@
   return m_stream;
 }
 
+FILE *NativeFile::ReleaseFILE(NativeFile &&file) {
+  FILE *stream = nullptr;
+  file.GetStream();
+  if (file.m_own_stream) {
+stream = file.m_stream;
+file.m_own_stream = false;
+file.m_stream = nullptr;
+  }
+  file.Close();
+  return stream;
+}
+
 Status NativeFile::Close() {
   Status error;
   if (StreamIsValid()) {
 if (m_own_stream) {
   if (::fclose(m_stream) == EOF)
 error.SetErrorToErrno();
-} else {
+} else if (m_options & eOpenOptionWrite) {
   if (::fflush(m_stream) == EOF)
 error.SetErrorToErrno();
 }
Index: lldb/packages/Python/lldbsuite/test/python_api/file_handle/TestFileHandle.py
===
--- lldb/packages/Python/lldbsuite/test/python_api/file_handle/TestFileHandle.py
+++ lldb/packages/Python/lldbsuite/test/python_api/file_handle/TestFileHandle.py
@@ -845,6 +845,7 @

[Lldb-commits] [PATCH] D69488: [LLDB][Python] fix another fflush issue on NetBSD

2019-10-28 Thread Lawrence D'Anna via Phabricator via lldb-commits

lawrence_danna added a comment.

There, I think that fixes the issue with borrow semantics and the NetBSD issues.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69488/new/

https://reviews.llvm.org/D69488



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

[Lldb-commits] [PATCH] D69488: [LLDB][Python] fix another fflush issue on NetBSD

2019-10-28 Thread Michał Górny via Phabricator via lldb-commits

mgorny added a comment.

Thanks but I'd personally prefer splitting this into a future commit, in case 
it introduced unrelated issues.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69488/new/

https://reviews.llvm.org/D69488



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

Re: [Lldb-commits] [PATCH] D69371: [ARM64] Cleanup and speedup NativeRegisterContextLinux_arm64

2019-10-28 Thread Omair Javaid via lldb-commits

On Fri, 25 Oct 2019 at 17:53, Pavel Labath via Phabricator
 wrote:
>
> labath added a comment.
>
> In D69371#1721077 , @omjavaid wrote:
>
> > We ll be dealing with Linux user mode and mostly aarch64 data registers 
> > except for cpsr, fpsr and fpcr. I think we should be fine but let me 
> > confirm this again from documentation.
>
>
> Right, but you're creating a general interface for all architectures, not 
> just several aarch64 registers. Even if they don't make use of that facility 
> now, it would be good to make sure they can do that in the future.
>
> For instance, on x86, the kernel may decide to reject 
> https://github.com/torvalds/linux/blob/master/arch/x86/kernel/ptrace.c#L187 
> some values of some registers, and silently ignore some bits in others 
> https://github.com/torvalds/linux/blob/master/arch/x86/kernel/ptrace.c#L349. 
> That's why I think it would be better to commit changes to memory 
> automatically/immediately, and minimize the chances that subsequent "read" 
> operations will return data which does not reflect the actual values held by 
> the OS.

So I gave  fixed or undefined bits a thought and also considered
implications of reading/writing certain status or control registers.
User visible registers dont really have big implications and we can
afford to keep user-corrupted values until resume as in theory all
state changes are going to happen on resume and target/thread state is
halted.

But even if we don't want the user to be writing fixed value bit
fields, we can easily choose to invalidate register caches in case of
certain registers.

For example
if (regno == cpsr)
   InvalidateAllRegisters().

In case of arm64, NativeRegisterContextLinux_arm64::WriteRegister may
call NativeRegisterContextLinux_arm64::InvalidateAllRegisters() if a
register like cpsr, fpsr or fpcr is being written.
Other architectures can use similar implementation or ignore register
caching altogether.

>
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D69371/new/
>
> https://reviews.llvm.org/D69371
>
>
>

-- 
Omair Javaid
www.linaro.org
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D69502: [LLDB] [PECOFF] Don't crash in ReadImageDataByRVA for addresses out of range

2019-10-28 Thread Martin Storsjö via Phabricator via lldb-commits

mstorsjo created this revision.
mstorsjo added reviewers: labath, amccarth, aleksandr.urakov.
Herald added subscribers: lldb-commits, JDevlieghere.
Herald added a project: LLDB.

This can happen e.g. when unwinding doesn't work perfectly.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D69502

Files:
  lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp


Index: lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
===
--- lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
+++ lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
@@ -564,7 +564,10 @@
 DataExtractor ObjectFilePECOFF::ReadImageDataByRVA(uint32_t rva, size_t size) {
   if (m_file) {
 Address addr = GetAddress(rva);
-rva = addr.GetSection()->GetFileOffset() + addr.GetOffset();
+SectionSP sect = addr.GetSection();
+if (!sect)
+  return {};
+rva = sect->GetFileOffset() + addr.GetOffset();
   }
 
   return ReadImageData(rva, size);


Index: lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
===
--- lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
+++ lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
@@ -564,7 +564,10 @@
 DataExtractor ObjectFilePECOFF::ReadImageDataByRVA(uint32_t rva, size_t size) {
   if (m_file) {
 Address addr = GetAddress(rva);
-rva = addr.GetSection()->GetFileOffset() + addr.GetOffset();
+SectionSP sect = addr.GetSection();
+if (!sect)
+  return {};
+rva = sect->GetFileOffset() + addr.GetOffset();
   }
 
   return ReadImageData(rva, size);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D69503: [LLDB] [Windows] Don't crash if the debugged process is unable to start up

2019-10-28 Thread Martin Storsjö via Phabricator via lldb-commits

mstorsjo created this revision.
mstorsjo added reviewers: labath, amccarth, aleksandr.urakov.
Herald added a subscriber: JDevlieghere.
Herald added a project: LLDB.

This can e.g. happen if the debugged executable depends on unavailable DLLs.

One could also return e.g. Status(ERROR_DLL_NOT_FOUND, eErrorTypeWin32) here, 
but I presume that can be overly specific as I'd guess this condition can 
occurr in other cases as well.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D69503

Files:
  lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.cpp


Index: lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
===
--- lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
+++ lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
@@ -574,6 +574,8 @@
 LLDB_LOG(log, "hit loader breakpoint, returning.");
 
 process = debugger->GetProcess();
+if (!m_session_data)
+  return Status("The process failed to launch.");
 return m_session_data->m_launch_error;
   } else
 return Status(::GetLastError(), eErrorTypeWin32);


Index: lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
===
--- lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
+++ lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
@@ -574,6 +574,8 @@
 LLDB_LOG(log, "hit loader breakpoint, returning.");
 
 process = debugger->GetProcess();
+if (!m_session_data)
+  return Status("The process failed to launch.");
 return m_session_data->m_launch_error;
   } else
 return Status(::GetLastError(), eErrorTypeWin32);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D68968: [android/process info] Introduce display_name

2019-10-28 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

This looks pretty good. I just have one quick question about the /comm file.




Comment at: lldb/source/Host/linux/Host.cpp:205-222
+static bool GetProcessNameFromStat(::pid_t pid, std::string& name) {
+  auto BufferOrError = getProcFile(pid, "stat");
+  if (!BufferOrError)
+return false;
+
+  std::unique_ptr Stat = std::move(*BufferOrError);
+  llvm::StringRef Rest = Stat->getBuffer();

This should return the same value as `/proc//comm`, except that you don't 
need to do any fancy parsing. Are there any cases where we cannot just read the 
/comm file ?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68968/new/

https://reviews.llvm.org/D68968



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

[Lldb-commits] [PATCH] D69502: [LLDB] [PECOFF] Don't crash in ReadImageDataByRVA for addresses out of range

2019-10-28 Thread Aleksandr Urakov via Phabricator via lldb-commits

aleksandr.urakov accepted this revision.
aleksandr.urakov added a comment.
This revision is now accepted and ready to land.

LGTM, thank you! Can you send me an example of binary on which unwinding fails 
with a crash, please? It is a very interesting case...


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69502/new/

https://reviews.llvm.org/D69502



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

[Lldb-commits] [PATCH] D69468: [LLDB][breakpoints] ArgInfo::count -> ArgInfo::max_positional_args

2019-10-28 Thread Pavel Labath via Phabricator via lldb-commits

labath added inline comments.



Comment at: lldb/scripts/Python/python-wrapper.swig:64
 
+unsigned max_positional_args = PythonCallable::ArgInfo::UNBOUNDED;
+if (auto arg_info = pfunc.GetArgInfo()) {

lawrence_danna wrote:
> labath wrote:
> > Is there any case where fetching the argument info will fail, but we still 
> > can successfully call the target object? Should we just bail out here?
> probably not? My thinking is that since there's no meaningful way to 
> return an error from this function we may as well try to call it and let the 
> exception get logged.   But I dunno.Should I change it?
Hmm... In that case, I think it would be better to print the error which caused 
the ArgInfo fetching to fail. Given that, in the new way of doing things, the 
`PyErr_Cleaner` object is not going to work anyway, we might as well use this 
opportunity to create a different mechanism for printing exceptions.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69468/new/

https://reviews.llvm.org/D69468



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

[Lldb-commits] [PATCH] D69019: [lldb] move package generation from python to cmake

2019-10-28 Thread Pavel Labath via Phabricator via lldb-commits

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Ok. sounds good.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69019/new/

https://reviews.llvm.org/D69019



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

[Lldb-commits] [PATCH] D69503: [LLDB] [Windows] Don't crash if the debugged process is unable to start up

2019-10-28 Thread Aleksandr Urakov via Phabricator via lldb-commits

aleksandr.urakov added a comment.

Sorry, I'm OOO today, so I can't take a precise look on this now. But I'm not 
sure, isn't race condition possible here on the m_session_data reset?


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69503/new/

https://reviews.llvm.org/D69503



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

[Lldb-commits] [PATCH] D69502: [LLDB] [PECOFF] Don't crash in ReadImageDataByRVA for addresses out of range

2019-10-28 Thread Martin Storsjö via Phabricator via lldb-commits

mstorsjo added a comment.

In D69502#1723385 , @aleksandr.urakov 
wrote:

> LGTM, thank you! Can you send me an example of binary on which unwinding 
> fails with a crash, please? It is a very interesting case...


It is on arm64, so it's not something that is expected to be flawless yet (even 
if it generally works, sometimes).


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69502/new/

https://reviews.llvm.org/D69502



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

[Lldb-commits] [PATCH] D69488: [LLDB][Python] fix another fflush issue on NetBSD

2019-10-28 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

I am not thrilled by all of that duping going around. Having multiple FILE 
objects means that you have multiple independent file caches too. That can 
cause different kinds of strange behavior if multiple things start 
reading/writing to the different FILE objects simultaneously. I think I'd 
rather just keep the existing borrow semantics. I don't think that should be a 
problem in practice -- it's just that this test is weird because is testing the 
extreme cases of this behavior (which is fine). Normally you'll just use one 
level of wrapping and so the underlying file will be naturally kept around, 
since lldb will still be holding onto it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69488/new/

https://reviews.llvm.org/D69488



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

[Lldb-commits] [PATCH] D69309: Support template instantiation in the expression evaluator

2019-10-28 Thread Raphael Isemann via Phabricator via lldb-commits

teemperor added a comment.

Will properly review this later, but this seems like a patch that might be 
related to the performance issue here: https://reviews.llvm.org/D41416


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69309/new/

https://reviews.llvm.org/D69309



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

[Lldb-commits] [PATCH] D69503: [LLDB] [Windows] Don't crash if the debugged process is unable to start up

2019-10-28 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

I don't know whether this is the right way to check for this, but at the very 
least is seems suspicious, as this function is called from LaunchProcess, which 
initializes m_session_data. This means that someone else needs to clear it in 
the mean time, and he probably does that asynchronously. Btw, have you read the 
comment in OnExitProcess() ? It seems that this code already tries to handle 
this case somehow...

Anyway, could you add a test for this? It should not be too hard to produce a 
missing dll in a test.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69503/new/

https://reviews.llvm.org/D69503



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

[Lldb-commits] [PATCH] D69502: [LLDB] [PECOFF] Don't crash in ReadImageDataByRVA for addresses out of range

2019-10-28 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

Any way to get a test for this? Maybe creating a object file with a bogus 
unwind RVA via yaml2obj ?


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69502/new/

https://reviews.llvm.org/D69502



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

Re: [Lldb-commits] [PATCH] D69371: [ARM64] Cleanup and speedup NativeRegisterContextLinux_arm64

2019-10-28 Thread Pavel Labath via lldb-commits


On 28/10/2019 11:57, Omair Javaid wrote:

On Fri, 25 Oct 2019 at 17:53, Pavel Labath via Phabricator
 wrote:


labath added a comment.

In D69371#1721077 , @omjavaid wrote:


We ll be dealing with Linux user mode and mostly aarch64 data registers except 
for cpsr, fpsr and fpcr. I think we should be fine but let me confirm this 
again from documentation.



Right, but you're creating a general interface for all architectures, not just 
several aarch64 registers. Even if they don't make use of that facility now, it 
would be good to make sure they can do that in the future.

For instance, on x86, the kernel may decide to reject 
https://github.com/torvalds/linux/blob/master/arch/x86/kernel/ptrace.c#L187 some values 
of some registers, and silently ignore some bits in others 
https://github.com/torvalds/linux/blob/master/arch/x86/kernel/ptrace.c#L349. That's why I 
think it would be better to commit changes to memory automatically/immediately, and 
minimize the chances that subsequent "read" operations will return data which 
does not reflect the actual values held by the OS.


So I gave  fixed or undefined bits a thought and also considered
implications of reading/writing certain status or control registers.
User visible registers dont really have big implications and we can
afford to keep user-corrupted values until resume as in theory all
state changes are going to happen on resume and target/thread state is
halted.


I don't agree with that assessment. While doing the register write 
"late" will not corrupt the state of the application, it will make it 
harder for the user to figure out what's going on. If we return the 
ptrace error immediately, the user will get an error message relating to 
the write command. If we don't do that, the command will appear to 
succeed, and even subsequent "read" commands will return new "bogus" 
value. If we postpone the write, we will get an error while processing 
the "continue" command. At that point we we only have two options: 
return an error (which will be interpreted as a failure to resume the 
process) or drop it (and leave the user wondering why did the register 
values suddenly change back).




But even if we don't want the user to be writing fixed value bit
fields, we can easily choose to invalidate register caches in case of
certain registers.

For example
if (regno == cpsr)
InvalidateAllRegisters().

In case of arm64, NativeRegisterContextLinux_arm64::WriteRegister may
call NativeRegisterContextLinux_arm64::InvalidateAllRegisters() if a
register like cpsr, fpsr or fpcr is being written.
Other architectures can use similar implementation or ignore register
caching altogether.



Yes, that is certainly possible, but it increases the code complexity ( 
== likelihood of something going wrong). Which is why I was asking what 
is the use case you are optimizing for. Is it reading of registers? Is 
it writing? Unwinding? Expression evaluation? Have you got any numbers? etc.


Register reads are a lot more common than writes, so I expect we can go 
a long way by just making sure the read operations don't cause ptrace 
traffic. As caching reads is a much safer option, I'd like to better 
understand the tradeoff here.


BTW, another thing which you might be interested in is 
. Once that patch lands, register reads 
should be done via the $g packet. That will increase the read speed much 
more than this patch, as it will cut out the link latency too (though I 
am still not opposed to caching stuff at lldb-server layer too).


pl
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D69502: [LLDB] [PECOFF] Don't crash in ReadImageDataByRVA for addresses out of range

2019-10-28 Thread Martin Storsjö via Phabricator via lldb-commits

mstorsjo added a comment.

In D69502#1723549 , @labath wrote:

> Any way to get a test for this? Maybe creating a object file with a bogus 
> unwind RVA via yaml2obj ?

Do we have a suitable test as basis for it? I'm not quite sure which way is the 
most compact way of achieving that. A small couple function exe with SEH or 
dwarf (eh_frame) unwind info, without debug info, with a crash/int3 in a nested 
function? Or just some image unwind commands so it doesn't need executing?

Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69502/new/

https://reviews.llvm.org/D69502

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

[Lldb-commits] [lldb] 6336317 - [Docs] Disable Python docs when LLDB_DISABLE_PYTHON is set

2019-10-28 Thread Jonas Devlieghere via lldb-commits


Author: Jonas Devlieghere
Date: 2019-10-28T09:53:58-07:00
New Revision: 6336317e0a37c246b7aea29a178c0d6fd3d12454

URL: 
https://github.com/llvm/llvm-project/commit/6336317e0a37c246b7aea29a178c0d6fd3d12454
DIFF: 
https://github.com/llvm/llvm-project/commit/6336317e0a37c246b7aea29a178c0d6fd3d12454.diff

LOG: [Docs] Disable Python docs when LLDB_DISABLE_PYTHON is set

This leads to a configuration error because we're trying to get a
property that doesn't exist:

get_target_property() called with non-existent target "swig_wrapper"

Added: 


Modified: 
lldb/docs/CMakeLists.txt

Removed: 




diff  --git a/lldb/docs/CMakeLists.txt b/lldb/docs/CMakeLists.txt
index bfdd50badf65..03d1fe99b85c 100644
--- a/lldb/docs/CMakeLists.txt
+++ b/lldb/docs/CMakeLists.txt
@@ -15,43 +15,45 @@ if(DOXYGEN_FOUND)
   )
 endif()
 
-find_program(EPYDOC_EXECUTABLE NAMES epydoc epydoc.py)
-if(EPYDOC_EXECUTABLE)
-  message(STATUS "Found epydoc - ${EPYDOC_EXECUTABLE}")
+if (NOT LLDB_DISABLE_PYTHON)
+  find_program(EPYDOC_EXECUTABLE NAMES epydoc epydoc.py)
+  if(EPYDOC_EXECUTABLE)
+message(STATUS "Found epydoc - ${EPYDOC_EXECUTABLE}")
 
-  find_program(DOT_EXECUTABLE dot)
-  if(DOT_EXECUTABLE)
-set(EPYDOC_OPTIONS ${EPYDOC_OPTIONS} --graph all --dotpath 
${DOT_EXECUTABLE})
-message(STATUS "Found dot - ${DOT_EXECUTABLE}")
-  endif()
+find_program(DOT_EXECUTABLE dot)
+if(DOT_EXECUTABLE)
+  set(EPYDOC_OPTIONS ${EPYDOC_OPTIONS} --graph all --dotpath 
${DOT_EXECUTABLE})
+  message(STATUS "Found dot - ${DOT_EXECUTABLE}")
+endif()
 
-  # Pretend to make a python package so that we can generate the reference.
-  # Because we don't build liblldb, epydoc will complain that the import of
-  # _lldb.so failed, but that doesn't prevent it from generating the docs.
-  file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/lldb)
-  get_target_property(lldb_scripts_dir swig_wrapper BINARY_DIR)
-  add_custom_target(lldb-python-doc-package
-COMMAND "${CMAKE_COMMAND}" -E copy "${lldb_scripts_dir}/lldb.py" 
"${CMAKE_CURRENT_BINARY_DIR}/lldb/__init__.py"
-COMMENT "Copying lldb.py to pretend package.")
-  add_dependencies(lldb-python-doc-package swig_wrapper)
+# Pretend to make a python package so that we can generate the reference.
+# Because we don't build liblldb, epydoc will complain that the import of
+# _lldb.so failed, but that doesn't prevent it from generating the docs.
+file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/lldb)
+get_target_property(lldb_scripts_dir swig_wrapper BINARY_DIR)
+add_custom_target(lldb-python-doc-package
+  COMMAND "${CMAKE_COMMAND}" -E copy "${lldb_scripts_dir}/lldb.py" 
"${CMAKE_CURRENT_BINARY_DIR}/lldb/__init__.py"
+  COMMENT "Copying lldb.py to pretend package.")
+add_dependencies(lldb-python-doc-package swig_wrapper)
 
-  set(DOC_DIR "${CMAKE_CURRENT_SOURCE_DIR}/doc")
-  file(MAKE_DIRECTORY "${DOC_DIR}")
-  add_custom_target(lldb-python-doc
-${EPYDOC_EXECUTABLE}
---html
-lldb
--o ${CMAKE_CURRENT_BINARY_DIR}/python_reference
---name "LLDB python API"
---url "http://lldb.llvm.org";
-${EPYDOC_OPTIONS}
-WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
-COMMENT "Generating LLDB Python API reference with epydoc" VERBATIM
-  )
-  add_dependencies(lldb-python-doc swig_wrapper lldb-python-doc-package)
-else()
-  message(STATUS "Could NOT find epydoc")
-endif()
+set(DOC_DIR "${CMAKE_CURRENT_SOURCE_DIR}/doc")
+file(MAKE_DIRECTORY "${DOC_DIR}")
+add_custom_target(lldb-python-doc
+  ${EPYDOC_EXECUTABLE}
+  --html
+  lldb
+  -o ${CMAKE_CURRENT_BINARY_DIR}/python_reference
+  --name "LLDB python API"
+  --url "http://lldb.llvm.org";
+  ${EPYDOC_OPTIONS}
+  WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
+  COMMENT "Generating LLDB Python API reference with epydoc" VERBATIM
+)
+add_dependencies(lldb-python-doc swig_wrapper lldb-python-doc-package)
+  else()
+message(STATUS "Could NOT find epydoc")
+  endif()
+endif ()
 
 if (LLVM_ENABLE_SPHINX)
   include(AddSphinxTarget)



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

Re: [Lldb-commits] [PATCH] D69502: [LLDB] [PECOFF] Don't crash in ReadImageDataByRVA for addresses out of range

2019-10-28 Thread Aleksandr Urakov via lldb-commits

May be the test for PECallFrameInfo will be helpful?

Martin Storsjö via Phabricator  schrieb am Mo.,
28. Okt. 2019, 19:43:

> mstorsjo added a comment.
>
> In D69502#1723549 , @labath
> wrote:
>
> > Any way to get a test for this? Maybe creating a object file with a
> bogus unwind RVA via yaml2obj ?
>
>
> Do we have a suitable test as basis for it? I'm not quite sure which way
> is the most compact way of achieving that. A small couple function exe with
> SEH or dwarf (eh_frame) unwind info, without debug info, with a crash/int3
> in a nested function? Or just some image unwind commands so it doesn't need
> executing?
>
>
> Repository:
>   rLLDB LLDB
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D69502/new/
>
> https://reviews.llvm.org/D69502
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D69468: [LLDB][breakpoints] ArgInfo::count -> ArgInfo::max_positional_args

2019-10-28 Thread Jim Ingham via lldb-commits

In the work I was doing with the scripted ThreadPlans & Breakpoint Callbacks, 
I've been introducing Status objects into these calls in python-wrapper.swig 
(usually you have to start from the ScriptInterpreter API's, so we can report 
errors.  That way I could catch errors with wrong number of arguments and the 
like.  Whenever that's possible it seems preferable.

Jim


> On Oct 28, 2019, at 7:28 AM, Pavel Labath via Phabricator 
>  wrote:
> 
> labath added inline comments.
> 
> 
> 
> Comment at: lldb/scripts/Python/python-wrapper.swig:64
> 
> +unsigned max_positional_args = PythonCallable::ArgInfo::UNBOUNDED;
> +if (auto arg_info = pfunc.GetArgInfo()) {
> 
> lawrence_danna wrote:
>> labath wrote:
>>> Is there any case where fetching the argument info will fail, but we still 
>>> can successfully call the target object? Should we just bail out here?
>> probably not? My thinking is that since there's no meaningful way to 
>> return an error from this function we may as well try to call it and let the 
>> exception get logged.   But I dunno.Should I change it?
> Hmm... In that case, I think it would be better to print the error which 
> caused the ArgInfo fetching to fail. Given that, in the new way of doing 
> things, the `PyErr_Cleaner` object is not going to work anyway, we might as 
> well use this opportunity to create a different mechanism for printing 
> exceptions.
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D69468/new/
> 
> https://reviews.llvm.org/D69468
> 
> 
> 

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

[Lldb-commits] [lldb] da2a4c2 - [Docs] Update source code link to Github

2019-10-28 Thread Jonas Devlieghere via lldb-commits


Author: Jonas Devlieghere
Date: 2019-10-28T11:14:59-07:00
New Revision: da2a4c234dcda0677d89051408b38d50d44991fe

URL: 
https://github.com/llvm/llvm-project/commit/da2a4c234dcda0677d89051408b38d50d44991fe
DIFF: 
https://github.com/llvm/llvm-project/commit/da2a4c234dcda0677d89051408b38d50d44991fe.diff

LOG: [Docs] Update source code link to Github

Added: 


Modified: 
lldb/docs/index.rst

Removed: 




diff  --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 7e287b1d9ae4..faabed9c691a 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -159,6 +159,6 @@ interesting areas to contribute to lldb.
:maxdepth: 1
:caption: External Links
 
-   Source Code 
+   Source Code 
Code Reviews 
Bug Reports 



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

[Lldb-commits] [PATCH] D68968: [android/process info] Introduce display_name

2019-10-28 Thread walter erquinigo via Phabricator via lldb-commits

wallace marked an inline comment as done.
wallace added inline comments.



Comment at: lldb/source/Host/linux/Host.cpp:205-222
+static bool GetProcessNameFromStat(::pid_t pid, std::string& name) {
+  auto BufferOrError = getProcFile(pid, "stat");
+  if (!BufferOrError)
+return false;
+
+  std::unique_ptr Stat = std::move(*BufferOrError);
+  llvm::StringRef Rest = Stat->getBuffer();

labath wrote:
> This should return the same value as `/proc//comm`, except that you 
> don't need to do any fancy parsing. Are there any cases where we cannot just 
> read the /comm file ?
you are right! I'll just use it directly


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68968/new/

https://reviews.llvm.org/D68968



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

[Lldb-commits] [PATCH] D69488: [LLDB][Python] fix another fflush issue on NetBSD

2019-10-28 Thread Lawrence D'Anna via Phabricator via lldb-commits

lawrence_danna added a comment.

In D69488#1723481 , @labath wrote:

> I am not thrilled by all of that duping going around. Having multiple FILE 
> objects means that you have multiple independent file caches too. That can 
> cause different kinds of strange behavior if multiple things start 
> reading/writing to the different FILE objects simultaneously. I think I'd 
> rather just keep the existing borrow semantics. I don't think that should be 
> a problem in practice -- it's just that this test is weird because is testing 
> the extreme cases of this behavior (which is fine). Normally you'll just use 
> one level of wrapping and so the underlying file will be naturally kept 
> around, since lldb will still be holding onto it.

I'm not exactly thrilled with it but I will still argue it is the right thing 
to do.   If you look at the docstring for `GetFile`, it doesn't mention this 
problem.   It says you can't use a borrowed file if it becomes dangling, but it 
doesn't say you have to delete your references to it before it can dangle.   
That's because this problem is surprising enough that neither of us thought of 
it.

Consider this situation:   The python programmer makes an object that keeps a 
reference to `debugger` and also to `debugger.GetOutputFile().GetFile()`.   
When they're done with the object they destroy the debugger and let their 
object go out of scope.

In python3, they may get an `IOError` at this point, as the saved output file 
tries to flush its buffer to a closed file.In python 2 they are exposed to 
to a use-after free violation and the program could crash!

It is very difficult to write  python programs that deal with these kind of 
semantics correctly, and nothing about this API suggests that it is as 
dangerous to use as that.  I think the correctness and ergonomics concerns 
outweigh the performance concerns here. Particularly because this issue 
only affects python 2. Is it really a bigger deal that we generate some 
extra dups on an end-of-life scripting language than that we potentially crash 
on that language?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69488/new/

https://reviews.llvm.org/D69488

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

[Lldb-commits] [PATCH] D69523: [debugserver] Detect arch from LLVM_DEFAULT_TARGET_TRIPLE

2019-10-28 Thread Vedant Kumar via Phabricator via lldb-commits

vsk created this revision.
vsk added reviewers: davide, JDevlieghere, xiaobai.
Herald added a subscriber: mgorny.

The debugserver build needs to conditionally include files depending on the
target architecture.

Switch on the architecture specified by LLVM_DEFAULT_TARGET_TRIPLE, as
the llvm and swift build systems use this variable to identify the
target (the latter, indirectly, through LLVM_HOST_TRIPLE).

It would be possible to switch on CMAKE_OSX_ARCHITECTURES, but the swift
build does not provide it, preferring instead to pass arch-specific
CFLAGS etc explicitly. Switching on LLVM_HOST_TRIPLE is also an option,
but it breaks down when cross-compiling.


https://reviews.llvm.org/D69523

Files:
  lldb/tools/debugserver/source/MacOSX/CMakeLists.txt


Index: lldb/tools/debugserver/source/MacOSX/CMakeLists.txt
===
--- lldb/tools/debugserver/source/MacOSX/CMakeLists.txt
+++ lldb/tools/debugserver/source/MacOSX/CMakeLists.txt
@@ -1,14 +1,28 @@
-if("${CMAKE_OSX_ARCHITECTURES}" MATCHES ".*arm.*")
+# The debugserver build needs to conditionally include files depending on the
+# target architecture.
+#
+# Switch on the architecture specified by LLVM_DEFAULT_TARGET_TRIPLE, as
+# the llvm and swift build systems use this variable to identify the
+# target (the latter, indirectly, through LLVM_HOST_TRIPLE).
+#
+# It would be possible to switch on CMAKE_OSX_ARCHITECTURES, but the swift
+# build does not provide it, preferring instead to pass arch-specific
+# CFLAGS etc explicitly. Switching on LLVM_HOST_TRIPLE is also an option,
+# but it breaks down when cross-compiling.
+
+string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH 
${LLVM_DEFAULT_TARGET_TRIPLE})
+
+if("${LLDB_DEBUGSERVER_ARCH}" MATCHES ".*arm.*")
   list(APPEND SOURCES arm/DNBArchImpl.cpp arm64/DNBArchImplARM64.cpp)
   include_directories(${CURRENT_SOURCE_DIR}/arm ${CURRENT_SOURCE_DIR}/arm64)
 endif()
 
-if(NOT CMAKE_OSX_ARCHITECTURES OR "${CMAKE_OSX_ARCHITECTURES}" MATCHES 
".*86.*")
+if(NOT LLDB_DEBUGSERVER_ARCH OR "${LLDB_DEBUGSERVER_ARCH}" MATCHES ".*86.*")
   list(APPEND SOURCES i386/DNBArchImplI386.cpp x86_64/DNBArchImplX86_64.cpp)
   include_directories(${CURRENT_SOURCE_DIR}/i386 ${CURRENT_SOURCE_DIR}/x86_64)
 endif()
 
-if("${CMAKE_OSX_ARCHITECTURES}" MATCHES ".*ppc.*")
+if("${LLDB_DEBUGSERVER_ARCH}" MATCHES ".*ppc.*")
   list(APPEND SOURCES ppc/DNBArchImpl.cpp)
   include_directories(${CURRENT_SOURCE_DIR}/ppc)
 endif()


Index: lldb/tools/debugserver/source/MacOSX/CMakeLists.txt
===
--- lldb/tools/debugserver/source/MacOSX/CMakeLists.txt
+++ lldb/tools/debugserver/source/MacOSX/CMakeLists.txt
@@ -1,14 +1,28 @@
-if("${CMAKE_OSX_ARCHITECTURES}" MATCHES ".*arm.*")
+# The debugserver build needs to conditionally include files depending on the
+# target architecture.
+#
+# Switch on the architecture specified by LLVM_DEFAULT_TARGET_TRIPLE, as
+# the llvm and swift build systems use this variable to identify the
+# target (the latter, indirectly, through LLVM_HOST_TRIPLE).
+#
+# It would be possible to switch on CMAKE_OSX_ARCHITECTURES, but the swift
+# build does not provide it, preferring instead to pass arch-specific
+# CFLAGS etc explicitly. Switching on LLVM_HOST_TRIPLE is also an option,
+# but it breaks down when cross-compiling.
+
+string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH ${LLVM_DEFAULT_TARGET_TRIPLE})
+
+if("${LLDB_DEBUGSERVER_ARCH}" MATCHES ".*arm.*")
   list(APPEND SOURCES arm/DNBArchImpl.cpp arm64/DNBArchImplARM64.cpp)
   include_directories(${CURRENT_SOURCE_DIR}/arm ${CURRENT_SOURCE_DIR}/arm64)
 endif()
 
-if(NOT CMAKE_OSX_ARCHITECTURES OR "${CMAKE_OSX_ARCHITECTURES}" MATCHES ".*86.*")
+if(NOT LLDB_DEBUGSERVER_ARCH OR "${LLDB_DEBUGSERVER_ARCH}" MATCHES ".*86.*")
   list(APPEND SOURCES i386/DNBArchImplI386.cpp x86_64/DNBArchImplX86_64.cpp)
   include_directories(${CURRENT_SOURCE_DIR}/i386 ${CURRENT_SOURCE_DIR}/x86_64)
 endif()
 
-if("${CMAKE_OSX_ARCHITECTURES}" MATCHES ".*ppc.*")
+if("${LLDB_DEBUGSERVER_ARCH}" MATCHES ".*ppc.*")
   list(APPEND SOURCES ppc/DNBArchImpl.cpp)
   include_directories(${CURRENT_SOURCE_DIR}/ppc)
 endif()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D69524: [debugserver] Delete macOS/PPC debug server implementation

2019-10-28 Thread Vedant Kumar via Phabricator via lldb-commits

vsk created this revision.
vsk added reviewers: clayborg, jasonmolenda.
Herald added subscribers: kbarton, mgorny, nemanjai.

macOS/PPC support was dropped in 10.6 (Snow Leopard).


https://reviews.llvm.org/D69524

Files:
  lldb/tools/debugserver/source/MacOSX/CMakeLists.txt
  lldb/tools/debugserver/source/MacOSX/ppc/DNBArchImpl.cpp
  lldb/tools/debugserver/source/MacOSX/ppc/DNBArchImpl.h

Index: lldb/tools/debugserver/source/MacOSX/ppc/DNBArchImpl.h
===
--- lldb/tools/debugserver/source/MacOSX/ppc/DNBArchImpl.h
+++ /dev/null
@@ -1,159 +0,0 @@
-//===-- DNBArchImpl.h ---*- C++ -*-===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===--===//
-//
-//  Created by Greg Clayton on 6/25/07.
-//
-//===--===//
-
-#ifndef __DebugNubArchMachPPC_h__
-#define __DebugNubArchMachPPC_h__
-
-#if defined(__powerpc__) || defined(__ppc__) || defined(__ppc64__)
-
-#include "DNBArch.h"
-
-class MachThread;
-
-class DNBArchMachPPC : public DNBArchProtocol {
-public:
-  DNBArchMachPPC(MachThread *thread) : m_thread(thread), m_state() {}
-
-  virtual ~DNBArchMachPPC() {}
-
-  virtual const DNBRegisterSetInfo *
-  GetRegisterSetInfo(nub_size_t *num_reg_sets) const;
-  virtual bool GetRegisterValue(uint32_t set, uint32_t reg,
-DNBRegisterValue *value) const;
-  virtual kern_return_t GetRegisterState(int set, bool force);
-  virtual kern_return_t SetRegisterState(int set);
-  virtual bool RegisterSetStateIsValid(int set) const;
-
-  virtual uint64_t GetPC(uint64_t failValue); // Get program counter
-  virtual kern_return_t SetPC(uint64_t value);
-  virtual uint64_t GetSP(uint64_t failValue); // Get stack pointer
-  virtual bool ThreadWillResume();
-  virtual bool ThreadDidStop();
-
-  static const uint8_t *SoftwareBreakpointOpcode(nub_size_t byte_size);
-  static uint32_t GetCPUType();
-
-protected:
-  kern_return_t EnableHardwareSingleStep(bool enable);
-
-  enum RegisterSet {
-e_regSetALL = REGISTER_SET_ALL,
-e_regSetGPR,
-e_regSetFPR,
-e_regSetEXC,
-e_regSetVEC,
-kNumRegisterSets
-  };
-
-  typedef enum RegisterSetWordSizeTag {
-e_regSetWordSizeGPR = PPC_THREAD_STATE_COUNT,
-e_regSetWordSizeFPR = PPC_FLOAT_STATE_COUNT,
-e_regSetWordSizeEXC = PPC_EXCEPTION_STATE_COUNT,
-e_regSetWordSizeVEC = PPC_VECTOR_STATE_COUNT
-  } RegisterSetWordSize;
-
-  enum { Read = 0, Write = 1, kNumErrors = 2 };
-
-  struct State {
-ppc_thread_state_t gpr;
-ppc_float_state_t fpr;
-ppc_exception_state_t exc;
-ppc_vector_state_t vec;
-kern_return_t gpr_errs[2]; // Read/Write errors
-kern_return_t fpr_errs[2]; // Read/Write errors
-kern_return_t exc_errs[2]; // Read/Write errors
-kern_return_t vec_errs[2]; // Read/Write errors
-
-State() {
-  uint32_t i;
-  for (i = 0; i < kNumErrors; i++) {
-gpr_errs[i] = -1;
-fpr_errs[i] = -1;
-exc_errs[i] = -1;
-vec_errs[i] = -1;
-  }
-}
-void InvalidateAllRegisterStates() { SetError(e_regSetALL, Read, -1); }
-kern_return_t GetError(int set, uint32_t err_idx) const {
-  if (err_idx < kNumErrors) {
-switch (set) {
-// When getting all errors, just OR all values together to see if
-// we got any kind of error.
-case e_regSetALL:
-  return gpr_errs[err_idx] | fpr_errs[err_idx] | exc_errs[err_idx] |
- vec_errs[err_idx];
-case e_regSetGPR:
-  return gpr_errs[err_idx];
-case e_regSetFPR:
-  return fpr_errs[err_idx];
-case e_regSetEXC:
-  return exc_errs[err_idx];
-case e_regSetVEC:
-  return vec_errs[err_idx];
-default:
-  break;
-}
-  }
-  return -1;
-}
-bool SetError(int set, uint32_t err_idx, kern_return_t err) {
-  if (err_idx < kNumErrors) {
-switch (set) {
-case e_regSetALL:
-  gpr_errs[err_idx] = fpr_errs[err_idx] = exc_errs[err_idx] =
-  vec_errs[err_idx] = err;
-  return true;
-
-case e_regSetGPR:
-  gpr_errs[err_idx] = err;
-  return true;
-
-case e_regSetFPR:
-  fpr_errs[err_idx] = err;
-  return true;
-
-case e_regSetEXC:
-  exc_errs[err_idx] = err;
-  return true;
-
-case e_regSetVEC:
-  vec_errs[err_idx] = err;
-  return true;
-
-default:
-  break;
-}
-  }
-  return false;
-}
-bool RegsAreValid(int set) const {
-  return GetError(set, Read) == KERN_SUCCESS;
-}
-  };
-
-  kern_return_t GetGPRState(bool

[Lldb-commits] [PATCH] D69453: Modernize TestThreadStepOut.py

2019-10-28 Thread Adrian Prantl via Phabricator via lldb-commits

aprantl added a comment.

Thanks! Nitpicking inside.




Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py:136
+(self.inferior_target, self.inferior_process, thread, bkpt) = 
lldbutil.run_to_source_breakpoint(
+self, self.bkpt_string, self.main_file, only_one_thread = False)
 

If `self.bkpt_string` and `self.main_file` are only used here, I would find 
this easier to read:

`ldbutil.run_to_source_breakpoint(self, 'break here', 
lldb.SBFileSpec('main.cpp'), only_one_thread = False)`



Comment at: lldb/packages/Python/lldbsuite/test/lldbutil.py:783
+if only_one_thread:
+test.assertTrue(len(threads) == 1, "Expected 1 thread to stop at 
breakpoint, %d did."%(len(threads)))
+else:

assertEquals! :-)



Comment at: lldb/packages/Python/lldbsuite/test/lldbutil.py:785
+else:
+test.assertTrue(len(threads) > 0, "No threads stopped at breakpoint")
+

`assertGreater` (see `.../unittest2/case.py`)


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69453/new/

https://reviews.llvm.org/D69453



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

[Lldb-commits] [PATCH] D69453: Modernize TestThreadStepOut.py

2019-10-28 Thread Adrian Prantl via Phabricator via lldb-commits

aprantl added inline comments.



Comment at: lldb/packages/Python/lldbsuite/test/lldbutil.py:781
 
-test.assertTrue(len(threads) == 1, "Expected 1 thread to stop at 
breakpoint, %d did."%(len(threads)))
+num_threads = len(threads)
+if only_one_thread:

this isn't used in the next condition?


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69453/new/

https://reviews.llvm.org/D69453



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

[Lldb-commits] [PATCH] D69468: [LLDB][breakpoints] ArgInfo::count -> ArgInfo::max_positional_args

2019-10-28 Thread Lawrence D'Anna via Phabricator via lldb-commits

lawrence_danna updated this revision to Diff 226737.
lawrence_danna added a comment.

improved error handling


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69468/new/

https://reviews.llvm.org/D69468

Files:
  lldb/include/lldb/Interpreter/ScriptInterpreter.h
  
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/TestBreakpointCommandsFromPython.py
  lldb/scripts/Python/python-wrapper.swig
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
  lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp

Index: lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
===
--- lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
+++ lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
@@ -59,7 +59,7 @@
 #define LLDBSwigPyInit init_lldb
 #endif
 
-extern "C" bool LLDBSwigPythonBreakpointCallbackFunction(
+extern "C" llvm::Expected LLDBSwigPythonBreakpointCallbackFunction(
 const char *python_function_name, const char *session_dictionary_name,
 const lldb::StackFrameSP &sb_frame,
 const lldb::BreakpointLocationSP &sb_bp_loc,
Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
@@ -256,11 +256,10 @@
   BreakpointOptions *bp_options,
   std::unique_ptr &data_up) override;
 
-  Status SetBreakpointCommandCallback(
-  BreakpointOptions *bp_options, 
-   const char *command_body_text,
-   StructuredData::ObjectSP extra_args_sp,
-   bool uses_extra_args);
+  Status SetBreakpointCommandCallback(BreakpointOptions *bp_options,
+  const char *command_body_text,
+  StructuredData::ObjectSP extra_args_sp,
+  bool uses_extra_args);
 
   /// Set a one-liner as the callback for the watchpoint.
   void SetWatchpointCommandCallback(WatchpointOptions *wp_options,
@@ -378,10 +377,9 @@
   python::PythonDictionary &GetSessionDictionary();
 
   python::PythonDictionary &GetSysModuleDictionary();
-  
-  llvm::Expected 
-  GetNumFixedArgumentsForCallable(const llvm::StringRef &callable_name) 
-  override;
+
+  llvm::Expected GetMaxPositionalArgumentsForCallable(
+  const llvm::StringRef &callable_name) override;
 
   bool GetEmbeddedInterpreterModuleObjects();
 
Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -72,11 +72,16 @@
 // These prototypes are the Pythonic implementations of the required callbacks.
 // Although these are scripting-language specific, their definition depends on
 // the public API.
-extern "C" bool LLDBSwigPythonBreakpointCallbackFunction(
+
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wreturn-type-c-linkage"
+
+extern "C" llvm::Expected LLDBSwigPythonBreakpointCallbackFunction(
 const char *python_function_name, const char *session_dictionary_name,
 const lldb::StackFrameSP &sb_frame,
-const lldb::BreakpointLocationSP &sb_bp_loc,
-StructuredDataImpl *args_impl);
+const lldb::BreakpointLocationSP &sb_bp_loc, StructuredDataImpl *args_impl);
+
+#pragma clang diagnostic pop
 
 extern "C" bool LLDBSwigPythonWatchpointCallbackFunction(
 const char *python_function_name, const char *session_dictionary_name,
@@ -782,10 +787,9 @@
   return m_sys_module_dict;
 }
 
-llvm::Expected
-ScriptInterpreterPythonImpl::GetNumFixedArgumentsForCallable(
-const llvm::StringRef &callable_name)
-{
+llvm::Expected
+ScriptInterpreterPythonImpl::GetMaxPositionalArgumentsForCallable(
+const llvm::StringRef &callable_name) {
   if (callable_name.empty()) {
 return llvm::createStringError(
 llvm::inconvertibleErrorCode(),
@@ -796,16 +800,15 @@
  Locker::NoSTDIN);
   auto dict = PythonModule::MainModule()
   .ResolveName(m_dictionary_name);
-  auto pfunc 
- = PythonObject::ResolveNameWithDictionary(callable_name, 
-   dict);
+  auto pfunc = PythonObject::ResolveNameWithDictionary(
+  callable_name, dict);
   if (!pfunc.IsAllocated()) {
 return llvm::createStringError(
 llvm::inconvertibleErrorCode(),
 "can't find callable: %s", callable_name.str().c_str());
   }
   PythonCallable::ArgInfo arg_info = pfunc.GetNumArguments();
-  return arg_info.count;
+  return arg_info

[Lldb-commits] [lldb] f8a92af - [LLDB] Remove incorrect dotest.py invocation

2019-10-28 Thread Jonas Devlieghere via lldb-commits


Author: Jonas Devlieghere
Date: 2019-10-28T13:24:07-07:00
New Revision: f8a92af893eee7ac7ffda93c24b9e69df506148f

URL: 
https://github.com/llvm/llvm-project/commit/f8a92af893eee7ac7ffda93c24b9e69df506148f
DIFF: 
https://github.com/llvm/llvm-project/commit/f8a92af893eee7ac7ffda93c24b9e69df506148f.diff

LOG: [LLDB] Remove incorrect dotest.py invocation

The invocation shown by dotest.py to re-run a single test is misleading:
it ranges from missing arguments (best case scenario) to being totally
wrong (worst case scenario).

In the past I've tried to get it right, but given the dotest
architecture this is harder than it looks. Furthermore, we have pretty
good documentation on the website [1] for most use cases.

This patch removes the rerun invocation.

[1] https://lldb.llvm.org/resources/test.html

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/lldbtest.py

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py 
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 34e6aa8f460d..f3165ab32585 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -1169,27 +1169,11 @@ def dumpSessionInfo(self):
 if test is self:
 print(traceback, file=self.session)
 
-# put footer (timestamp/rerun instructions) into session
-testMethod = getattr(self, self._testMethodName)
-if getattr(testMethod, "__benchmarks_test__", False):
-benchmarks = True
-else:
-benchmarks = False
-
 import datetime
 print(
 "Session info generated @",
 datetime.datetime.now().ctime(),
 file=self.session)
-print(
-"To rerun this test, issue the following command from the 'test' 
directory:\n",
-file=self.session)
-print(
-"./dotest.py %s -v %s %s" %
-(self.getRunOptions(),
- ('+b' if benchmarks else '-t'),
-self.getRerunArgs()),
-file=self.session)
 self.session.close()
 del self.session
 



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

[Lldb-commits] [PATCH] D68968: [android/process info] Introduce display_name

2019-10-28 Thread walter erquinigo via Phabricator via lldb-commits

wallace updated this revision to Diff 226744.
wallace added a comment.

now reading from comm


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68968/new/

https://reviews.llvm.org/D68968

Files:
  lldb/docs/lldb-gdb-remote.txt
  lldb/include/lldb/Utility/ProcessInfo.h
  
lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestPlatformClient.py
  lldb/source/Host/linux/Host.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
  lldb/source/Utility/ProcessInfo.cpp

Index: lldb/source/Utility/ProcessInfo.cpp
===
--- lldb/source/Utility/ProcessInfo.cpp
+++ lldb/source/Utility/ProcessInfo.cpp
@@ -38,11 +38,18 @@
   m_pid = LLDB_INVALID_PROCESS_ID;
 }
 
+// On systems like android, there are cases in which a process name can
+// correspond to a bundle id (e.g. com.test.app), which is not an executable
+// path.
 const char *ProcessInfo::GetName() const {
+  if (!m_display_name.empty())
+return m_display_name.c_str();
   return m_executable.GetFilename().GetCString();
 }
 
 llvm::StringRef ProcessInfo::GetNameAsStringRef() const {
+  if (!m_display_name.empty())
+return m_display_name;
   return m_executable.GetFilename().GetStringRef();
 }
 
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
@@ -1187,14 +1187,16 @@
   response.PutCString("name:");
   response.PutStringAsRawHex8(proc_info.GetExecutableFile().GetCString());
 
-  response.PutChar(';');
-  response.PutCString("args:");
+  response.PutCString(";args:");
   response.PutStringAsRawHex8(proc_info.GetArg0());
   for (auto &arg : proc_info.GetArguments()) {
 response.PutChar('-');
 response.PutStringAsRawHex8(arg.ref());
   }
 
+  response.PutCString(";display_name:");
+  response.PutStringAsRawHex8(proc_info.GetDisplayName());
+
   response.PutChar(';');
   const ArchSpec &proc_arch = proc_info.GetArchitecture();
   if (proc_arch.IsValid()) {
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
@@ -1948,6 +1948,11 @@
 process_info.GetArguments().AppendArgument(arg);
   is_arg0 = false;
 }
+  } else if (name.equals("display_name")) {
+StringExtractor extractor(value);
+std::string display_name;
+extractor.GetHexByteString(display_name);
+process_info.SetDisplayName(display_name);
   } else if (name.equals("cputype")) {
 value.getAsInteger(0, cpu);
   } else if (name.equals("cpusubtype")) {
Index: lldb/source/Host/linux/Host.cpp
===
--- lldb/source/Host/linux/Host.cpp
+++ lldb/source/Host/linux/Host.cpp
@@ -202,6 +202,40 @@
   }
 }
 
+static bool GetProcessNameFromComm(::pid_t pid, std::string& name) {
+  auto BufferOrError = getProcFile(pid, "comm");
+  if (!BufferOrError)
+return false;
+
+  std::unique_ptr Stat = std::move(*BufferOrError);
+  llvm::StringRef Content = Stat->getBuffer();
+  if (Content.empty())
+return false;
+
+  // comm might end with new line
+  name = Content.trim();
+  return true;
+}
+
+static void SetProcessDisplayName(::pid_t pid, ProcessInstanceInfo& process_info) {
+  if (!process_info.GetNameAsStringRef().empty())
+return;
+  if (!process_info.GetArg0().empty()) {
+  // When /proc//exe is not readable, then we use arg0 as display name.
+  // On Android devices this might contain the apk package name.
+  process_info.SetDisplayName(process_info.GetArg0());
+  return;
+  }
+  // If /proc//cmdline is not readable, then it might correspond to a kernel thread
+  // or system process. We fallback to reading from /proc/stat for a display name.
+  std::string name;
+  if (GetProcessNameFromComm(pid, name)) {
+// We follow the guideline of surrounding the name with brackets, as explained here
+// https://unix.stackexchange.com/questions/22121/what-do-the-brackets-around-processes-mean
+process_info.SetDisplayName("[" + name + "]");
+  }
+}
+
 static bool GetProcessAndStatInfo(::pid_t pid,
   ProcessInstanceInfo &process_info,
   ProcessState &State, ::pid_t &tracerpid) {
@@ -213,6 +247,8 @@
   GetExePathAndArch(pid, process_info);
   GetProcessArgs(pid, process_info);
   GetProcessEnviron(pid, process_info);
+  // Get fallback display name
+  Set

[Lldb-commits] [PATCH] D69488: [LLDB][Python] fix another fflush issue on NetBSD

2019-10-28 Thread Michał Górny via Phabricator via lldb-commits

mgorny added a comment.

I have confirmed that your previous revision fixed the problem in question. The 
newer one would probably require full test suite run which I can't do right 
now. As I said, I would prefer those two changes to be committed separately, 
preferably with a few hours delay so that it would be clear if it causes any 
breakage on buildbot.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69488/new/

https://reviews.llvm.org/D69488



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

Re: [Lldb-commits] [lldb] f8a92af - [LLDB] Remove incorrect dotest.py invocation

2019-10-28 Thread Adrian McCarthy via lldb-commits

It looks like this was the only call to getRerunArgs, so why not delete it?

On Mon, Oct 28, 2019 at 1:24 PM Jonas Devlieghere via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

>
> Author: Jonas Devlieghere
> Date: 2019-10-28T13:24:07-07:00
> New Revision: f8a92af893eee7ac7ffda93c24b9e69df506148f
>
> URL:
> https://github.com/llvm/llvm-project/commit/f8a92af893eee7ac7ffda93c24b9e69df506148f
> DIFF:
> https://github.com/llvm/llvm-project/commit/f8a92af893eee7ac7ffda93c24b9e69df506148f.diff
>
> LOG: [LLDB] Remove incorrect dotest.py invocation
>
> The invocation shown by dotest.py to re-run a single test is misleading:
> it ranges from missing arguments (best case scenario) to being totally
> wrong (worst case scenario).
>
> In the past I've tried to get it right, but given the dotest
> architecture this is harder than it looks. Furthermore, we have pretty
> good documentation on the website [1] for most use cases.
>
> This patch removes the rerun invocation.
>
> [1] https://lldb.llvm.org/resources/test.html
>
> Added:
>
>
> Modified:
> lldb/packages/Python/lldbsuite/test/lldbtest.py
>
> Removed:
>
>
>
>
> 
> diff  --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py
> b/lldb/packages/Python/lldbsuite/test/lldbtest.py
> index 34e6aa8f460d..f3165ab32585 100644
> --- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
> +++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
> @@ -1169,27 +1169,11 @@ def dumpSessionInfo(self):
>  if test is self:
>  print(traceback, file=self.session)
>
> -# put footer (timestamp/rerun instructions) into session
> -testMethod = getattr(self, self._testMethodName)
> -if getattr(testMethod, "__benchmarks_test__", False):
> -benchmarks = True
> -else:
> -benchmarks = False
> -
>  import datetime
>  print(
>  "Session info generated @",
>  datetime.datetime.now().ctime(),
>  file=self.session)
> -print(
> -"To rerun this test, issue the following command from the
> 'test' directory:\n",
> -file=self.session)
> -print(
> -"./dotest.py %s -v %s %s" %
> -(self.getRunOptions(),
> - ('+b' if benchmarks else '-t'),
> -self.getRerunArgs()),
> -file=self.session)
>  self.session.close()
>  del self.session
>
>
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D69488: [LLDB][Python] fix another fflush issue on NetBSD

2019-10-28 Thread Lawrence D'Anna via Phabricator via lldb-commits

lawrence_danna added a comment.

In D69488#1724178 , @mgorny wrote:

> I have confirmed that your previous revision fixed the problem in question. 
> The newer one would probably require full test suite run which I can't do 
> right now. As I said, I would prefer those two changes to be committed 
> separately, preferably with a few hours delay so that it would be clear if it 
> causes any breakage on buildbot.


which commit id did you test?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69488/new/

https://reviews.llvm.org/D69488



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

[Lldb-commits] [PATCH] D69488: [LLDB][Python] fix another fflush issue on NetBSD

2019-10-28 Thread Lawrence D'Anna via Phabricator via lldb-commits

lawrence_danna updated this revision to Diff 226747.
lawrence_danna added a comment.

revert to previous version


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69488/new/

https://reviews.llvm.org/D69488

Files:
  lldb/packages/Python/lldbsuite/test/python_api/file_handle/TestFileHandle.py
  lldb/source/Host/common/File.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h


Index: lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
===
--- lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
+++ lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
@@ -189,6 +189,14 @@
  "key not in dict");
 }
 
+#if PY_MAJOR_VERSION < 3
+// The python 2 API declares some arguments as char* that should
+// be const char *, but it doesn't actually modify them.
+inline char *py2_const_cast(const char *s) { return const_cast(s); }
+#else
+inline const char *py2_const_cast(const char *s) { return s; }
+#endif
+
 enum class PyInitialValue { Invalid, Empty };
 
 template  struct PythonFormat;
@@ -309,16 +317,6 @@
 
   StructuredData::ObjectSP CreateStructuredObject() const;
 
-protected:
-
-#if PY_MAJOR_VERSION < 3
-  // The python 2 API declares some arguments as char* that should
-  // be const char *, but it doesn't actually modify them.
-  static char *py2_const_cast(const char *s) { return const_cast(s); }
-#else
-  static const char *py2_const_cast(const char *s) { return s; }
-#endif
-
 public:
   template 
   llvm::Expected CallMethod(const char *name,
Index: lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
@@ -1502,12 +1502,19 @@
   file_obj = PyFile_FromFd(file.GetDescriptor(), nullptr, mode, -1, nullptr,
"ignore", nullptr, 0);
 #else
-  // Read through the Python source, doesn't seem to modify these strings
-  char *cmode = const_cast(mode);
   // We pass ::flush instead of ::fclose here so we borrow the FILE* --
-  // the lldb_private::File still owns it.
-  file_obj =
-  PyFile_FromFile(file.GetStream(), const_cast(""), cmode, 
::fflush);
+  // the lldb_private::File still owns it.   NetBSD does not allow
+  // input files to be flushed, so we have to check for that case too.
+  int (*closer)(FILE *);
+  auto opts = file.GetOptions();
+  if (!opts)
+return opts.takeError();
+  if (opts.get() & File::eOpenOptionWrite)
+closer = ::fflush;
+  else
+closer = [](FILE *) { return 0; };
+  file_obj = PyFile_FromFile(file.GetStream(), py2_const_cast(""),
+ py2_const_cast(mode), closer);
 #endif
 
   if (!file_obj)
Index: lldb/source/Host/common/File.cpp
===
--- lldb/source/Host/common/File.cpp
+++ lldb/source/Host/common/File.cpp
@@ -310,7 +310,7 @@
 if (m_own_stream) {
   if (::fclose(m_stream) == EOF)
 error.SetErrorToErrno();
-} else {
+} else if (m_options & eOpenOptionWrite) {
   if (::fflush(m_stream) == EOF)
 error.SetErrorToErrno();
 }
Index: 
lldb/packages/Python/lldbsuite/test/python_api/file_handle/TestFileHandle.py
===
--- lldb/packages/Python/lldbsuite/test/python_api/file_handle/TestFileHandle.py
+++ lldb/packages/Python/lldbsuite/test/python_api/file_handle/TestFileHandle.py
@@ -845,11 +845,16 @@
 def i(sbf):
 for i in range(10):
 f = sbf.GetFile()
+self.assertEqual(f.mode, "w")
 yield f
 sbf = lldb.SBFile.Create(f, borrow=True)
 yield sbf
 sbf.Write(str(i).encode('ascii') + b"\n")
 files = list(i(sbf))
+# delete them in reverse order, again because each is a borrow
+# of the previous.
+while files:
+files.pop()
 with open(self.out_filename, 'r') as f:
 self.assertEqual(list(range(10)), list(map(int, 
f.read().strip().split(
 


Index: lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
===
--- lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
+++ lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
@@ -189,6 +189,14 @@
  "key not in dict");
 }
 
+#if PY_MAJOR_VERSION < 3
+// The python 2 API declares some arguments as char* that should
+// be const char *, but it doesn't actually modify them.
+inline char *py2_const_cast(c

[Lldb-commits] [PATCH] D69532: [LLDB][PythonFile] fix dangerous borrow semantics on python2

2019-10-28 Thread Lawrence D'Anna via Phabricator via lldb-commits

lawrence_danna created this revision.
lawrence_danna added reviewers: labath, mgorny.
Herald added a project: LLDB.

It is, I think, inherently unsafe to hand a borrowed native file 
object to a python program on python 2.   This is because the python 
file object must be created with a FILE*, not a descriptor. Even 
holding on to such a reference past its legal scope can result in
use-after-free violations.   Pytyhon programs are not prepared to deal
with that kind of requirement.

Python 3 does not suffer from this issue.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69532

Files:
  lldb/include/lldb/Host/File.h
  lldb/packages/Python/lldbsuite/test/python_api/file_handle/TestFileHandle.py
  lldb/source/Host/common/File.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp


Index: lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
@@ -1502,19 +1502,28 @@
   file_obj = PyFile_FromFd(file.GetDescriptor(), nullptr, mode, -1, nullptr,
"ignore", nullptr, 0);
 #else
-  // We pass ::flush instead of ::fclose here so we borrow the FILE* --
-  // the lldb_private::File still owns it.   NetBSD does not allow
-  // input files to be flushed, so we have to check for that case too.
-  int (*closer)(FILE *);
-  auto opts = file.GetOptions();
+  // It's more or less safe to let a python program borrow a file descriptor.
+  // If they let it dangle and then use it, they'll probably get an exception.
+  // The worst that can happen is they'll wind up doing IO on the wrong
+  // descriptor.   But it would be very unsafe to let a python program borrow
+  // a FILE*.   They could actually crash the program just by keeping a
+  // reference to it around.Since in python 2 we must have a FILE* and
+  // not a descriptor, we dup the descriptor and fdopen a new FILE* to it
+  // so python can have something it can own safely.
+  auto opts = File::GetOptionsFromMode(mode);
   if (!opts)
 return opts.takeError();
-  if (opts.get() & File::eOpenOptionWrite)
-closer = ::fflush;
-  else
-closer = [](FILE *) { return 0; };
-  file_obj = PyFile_FromFile(file.GetStream(), py2_const_cast(""),
- py2_const_cast(mode), closer);
+  int fd = file.GetDescriptor();
+  if (!File::DescriptorIsValid(fd))
+return llvm::createStringError(llvm::inconvertibleErrorCode(),
+   "File has no file descriptor");
+  NativeFile dupfile(fd, opts.get(), false);
+  FILE *stream = NativeFile::ReleaseFILE(std::move(dupfile));
+  if (!stream)
+return llvm::createStringError(llvm::inconvertibleErrorCode(),
+   "could not create FILE* stream");
+  file_obj = PyFile_FromFile(stream, py2_const_cast(""), py2_const_cast(mode),
+ ::fclose);
 #endif
 
   if (!file_obj)
Index: lldb/source/Host/common/File.cpp
===
--- lldb/source/Host/common/File.cpp
+++ lldb/source/Host/common/File.cpp
@@ -304,6 +304,18 @@
   return m_stream;
 }
 
+FILE *NativeFile::ReleaseFILE(NativeFile &&file) {
+  FILE *stream = nullptr;
+  file.GetStream();
+  if (file.m_own_stream) {
+stream = file.m_stream;
+file.m_own_stream = false;
+file.m_stream = nullptr;
+  }
+  file.Close();
+  return stream;
+}
+
 Status NativeFile::Close() {
   Status error;
   if (StreamIsValid()) {
Index: 
lldb/packages/Python/lldbsuite/test/python_api/file_handle/TestFileHandle.py
===
--- lldb/packages/Python/lldbsuite/test/python_api/file_handle/TestFileHandle.py
+++ lldb/packages/Python/lldbsuite/test/python_api/file_handle/TestFileHandle.py
@@ -851,10 +851,6 @@
 yield sbf
 sbf.Write(str(i).encode('ascii') + b"\n")
 files = list(i(sbf))
-# delete them in reverse order, again because each is a borrow
-# of the previous.
-while files:
-files.pop()
 with open(self.out_filename, 'r') as f:
 self.assertEqual(list(range(10)), list(map(int, 
f.read().strip().split(
 
Index: lldb/include/lldb/Host/File.h
===
--- lldb/include/lldb/Host/File.h
+++ lldb/include/lldb/Host/File.h
@@ -411,6 +411,8 @@
   size_t PrintfVarArg(const char *format, va_list args) override;
   llvm::Expected GetOptions() const override;
 
+  static FILE *ReleaseFILE(NativeFile &&file);
+
   static char ID;
   virtual bool isA(const void *classID) const override {
 return classID == &ID || File::isA(classID);


Index: lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
===

[Lldb-commits] [lldb] de2c7ca - Add support for DW_AT_export_symbols for anonymous structs

2019-10-28 Thread via lldb-commits


Author: shafik
Date: 2019-10-28T14:26:54-07:00
New Revision: de2c7cab715e195c9d559d317beb760cf0b95262

URL: 
https://github.com/llvm/llvm-project/commit/de2c7cab715e195c9d559d317beb760cf0b95262
DIFF: 
https://github.com/llvm/llvm-project/commit/de2c7cab715e195c9d559d317beb760cf0b95262.diff

LOG: Add support for DW_AT_export_symbols for anonymous structs

Summary:
We add support for DW_AT_export_symbols to detect anonymous struct on top of 
the heuristics implemented in D66175
This should allow us to differentiate anonymous structs and unnamed structs.
We also fix TestTypeList.py which was incorrectly detecting an unnamed struct 
as an anonymous struct.

Differential Revision: https://reviews.llvm.org/D68961

Added: 
lldb/test/Shell/SymbolFile/DWARF/anon_class_w_and_wo_export_symbols.ll

lldb/test/Shell/SymbolFile/DWARF/clang-ast-from-dwarf-unamed-and-anon-structs.cpp

Modified: 
lldb/include/lldb/Symbol/ClangASTContext.h
lldb/packages/Python/lldbsuite/test/python_api/type/TestTypeList.py
lldb/packages/Python/lldbsuite/test/python_api/type/main.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
lldb/source/Symbol/ClangASTContext.cpp

Removed: 




diff  --git a/lldb/include/lldb/Symbol/ClangASTContext.h 
b/lldb/include/lldb/Symbol/ClangASTContext.h
index c5d840973ae6..e59e756276c8 100644
--- a/lldb/include/lldb/Symbol/ClangASTContext.h
+++ b/lldb/include/lldb/Symbol/ClangASTContext.h
@@ -261,7 +261,8 @@ class ClangASTContext : public TypeSystem {
   CompilerType CreateRecordType(clang::DeclContext *decl_ctx,
 lldb::AccessType access_type, const char *name,
 int kind, lldb::LanguageType language,
-ClangASTMetadata *metadata = nullptr);
+ClangASTMetadata *metadata = nullptr,
+bool exports_symbols = false);
 
   class TemplateParameterInfos {
   public:

diff  --git 
a/lldb/packages/Python/lldbsuite/test/python_api/type/TestTypeList.py 
b/lldb/packages/Python/lldbsuite/test/python_api/type/TestTypeList.py
index b3b321c6ca8c..75a793a95b29 100644
--- a/lldb/packages/Python/lldbsuite/test/python_api/type/TestTypeList.py
+++ b/lldb/packages/Python/lldbsuite/test/python_api/type/TestTypeList.py
@@ -73,13 +73,17 @@ def test(self):
 self.assertTrue(enum_member)
 self.DebugSBType(enum_member.type)
 elif field.name == "my_type_is_nameless":
-self.assertTrue(
+self.assertFalse(
 field.type.IsAnonymousType(),
-"my_type_is_nameless has an anonymous type")
+"my_type_is_nameless is not an anonymous type")
 elif field.name == "my_type_is_named":
 self.assertFalse(
 field.type.IsAnonymousType(),
 "my_type_is_named has a named type")
+elif field.name == None:
+self.assertTrue(
+field.type.IsAnonymousType(),
+"Nameless type is not anonymous")
 
 # Pass an empty string.  LLDB should not crash. :-)
 fuzz_types = target.FindTypes(None)

diff  --git a/lldb/packages/Python/lldbsuite/test/python_api/type/main.cpp 
b/lldb/packages/Python/lldbsuite/test/python_api/type/main.cpp
index 8f5b93927c7f..b43b617b0f90 100644
--- a/lldb/packages/Python/lldbsuite/test/python_api/type/main.cpp
+++ b/lldb/packages/Python/lldbsuite/test/python_api/type/main.cpp
@@ -15,6 +15,14 @@ class Task {
 TASK_TYPE_1,
 TASK_TYPE_2
 } type;
+// This struct is anonymous b/c it does not have a name
+// and it is not unnamed class.
+// Anonymous classes are a GNU extension.
+struct {
+  int y;
+};
+// This struct is an unnamed class see [class.pre]p1
+// http://eel.is/c++draft/class#pre-1.sentence-6
 struct {
   int x;
 } my_type_is_nameless;

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 636e6032b877..42e25f727e4b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -347,6 +347,9 @@ ParsedDWARFTypeAttributes::ParsedDWARFTypeAttributes(const 
DWARFDIE &die) {
 case DW_AT_GNU_vector:
   is_vector = form_value.Boolean();
   break;
+case DW_AT_export_symbols:
+  exports_symbols = form_value.Boolean();
+  break;
 }
   }
 }
@@ -1546,7 +1549,7 @@ DWARFASTParserClang::ParseStructureLikeDIE(const DWARFDIE 
&die,
   clang_type_was_created = true;
   clang_type = m_ast.CreateRecordType(

[Lldb-commits] [PATCH] D69535: build: improve python check for Windows

2019-10-28 Thread Saleem Abdulrasool via Phabricator via lldb-commits

compnerd created this revision.
compnerd added reviewers: xiaobai, stella.stamenova.
Herald added subscribers: JDevlieghere, mgorny.
Herald added a project: LLDB.

If we have a new enough CMake, use `find_package(Python3)`.  This version is 
able to check both 32-bit and 64-bit versions and will setup everything 
properly without the user needing to specify `PYTHON_HOME`.  This enables 
building lldb's python bindings on Windows under Azure's CI again.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D69535

Files:
  lldb/cmake/modules/LLDBConfig.cmake


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -221,34 +221,43 @@
 endfunction(find_python_libs_windows)
 
 if (NOT LLDB_DISABLE_PYTHON)
-  if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
-find_python_libs_windows()
-
-if (NOT LLDB_RELOCATABLE_PYTHON)
-  file(TO_CMAKE_PATH "${PYTHON_HOME}" LLDB_PYTHON_HOME)
-  add_definitions( -DLLDB_PYTHON_HOME="${LLDB_PYTHON_HOME}" )
+  if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.13 AND CMAKE_SYSTEM_NAME STREQUAL 
Windows)
+find_package(Python3 COMPONENTS Interpreter Development REQUIRED)
+if(Python3_VERSION VERSION_LESS 3.5)
+  message(FATAL_ERROR "Python 3.5 or newer is required (found: 
${Python3_VERSION})")
 endif()
+set(PYTHON_LIBRARY ${Python3_LIBRARIES})
+include_directories(${Python3_INCLUDE_DIRS})
   else()
-find_package(PythonInterp REQUIRED)
-find_package(PythonLibs REQUIRED)
-  endif()
+if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
+  find_python_libs_windows()
+
+  if (NOT LLDB_RELOCATABLE_PYTHON)
+file(TO_CMAKE_PATH "${PYTHON_HOME}" LLDB_PYTHON_HOME)
+add_definitions( -DLLDB_PYTHON_HOME="${LLDB_PYTHON_HOME}" )
+  endif()
+else()
+  find_package(PythonInterp REQUIRED)
+  find_package(PythonLibs REQUIRED)
+endif()
 
-  if (NOT CMAKE_CROSSCOMPILING)
-string(REPLACE "." ";" pythonlibs_version_list 
${PYTHONLIBS_VERSION_STRING})
-list(GET pythonlibs_version_list 0 pythonlibs_major)
-list(GET pythonlibs_version_list 1 pythonlibs_minor)
-
-# Ignore the patch version. Some versions of macOS report a different patch
-# version for the system provided interpreter and libraries.
-if (NOT PYTHON_VERSION_MAJOR VERSION_EQUAL pythonlibs_major OR
-NOT PYTHON_VERSION_MINOR VERSION_EQUAL pythonlibs_minor)
-  message(FATAL_ERROR "Found incompatible Python interpreter 
(${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})"
-  " and Python libraries 
(${pythonlibs_major}.${pythonlibs_minor})")
+if (NOT CMAKE_CROSSCOMPILING)
+  string(REPLACE "." ";" pythonlibs_version_list 
${PYTHONLIBS_VERSION_STRING})
+  list(GET pythonlibs_version_list 0 pythonlibs_major)
+  list(GET pythonlibs_version_list 1 pythonlibs_minor)
+
+  # Ignore the patch version. Some versions of macOS report a different 
patch
+  # version for the system provided interpreter and libraries.
+  if (NOT PYTHON_VERSION_MAJOR VERSION_EQUAL pythonlibs_major OR
+  NOT PYTHON_VERSION_MINOR VERSION_EQUAL pythonlibs_minor)
+message(FATAL_ERROR "Found incompatible Python interpreter 
(${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})"
+" and Python libraries 
(${pythonlibs_major}.${pythonlibs_minor})")
+  endif()
 endif()
-  endif()
 
-  if (PYTHON_INCLUDE_DIR)
-include_directories(${PYTHON_INCLUDE_DIR})
+if (PYTHON_INCLUDE_DIR)
+  include_directories(${PYTHON_INCLUDE_DIR})
+endif()
   endif()
 endif()
 


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -221,34 +221,43 @@
 endfunction(find_python_libs_windows)
 
 if (NOT LLDB_DISABLE_PYTHON)
-  if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
-find_python_libs_windows()
-
-if (NOT LLDB_RELOCATABLE_PYTHON)
-  file(TO_CMAKE_PATH "${PYTHON_HOME}" LLDB_PYTHON_HOME)
-  add_definitions( -DLLDB_PYTHON_HOME="${LLDB_PYTHON_HOME}" )
+  if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.13 AND CMAKE_SYSTEM_NAME STREQUAL Windows)
+find_package(Python3 COMPONENTS Interpreter Development REQUIRED)
+if(Python3_VERSION VERSION_LESS 3.5)
+  message(FATAL_ERROR "Python 3.5 or newer is required (found: ${Python3_VERSION})")
 endif()
+set(PYTHON_LIBRARY ${Python3_LIBRARIES})
+include_directories(${Python3_INCLUDE_DIRS})
   else()
-find_package(PythonInterp REQUIRED)
-find_package(PythonLibs REQUIRED)
-  endif()
+if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
+  find_python_libs_windows()
+
+  if (NOT LLDB_RELOCATABLE_PYTHON)
+file(TO_CMAKE_PATH "${PYTHON_HOME}" LLDB_PYTHON_HOME)
+add_definitions( -DLLDB_PYTHON_HOME="${LLDB_PYTHON_HOME}" )
+  en

[Lldb-commits] [lldb] 5ae881f - [Docs] Repurpose 'sources' page as 'contributing'.

2019-10-28 Thread Jonas Devlieghere via lldb-commits


Author: Jonas Devlieghere
Date: 2019-10-28T15:03:05-07:00
New Revision: 5ae881f96f999aaca98d8f83d3f00e037c783647

URL: 
https://github.com/llvm/llvm-project/commit/5ae881f96f999aaca98d8f83d3f00e037c783647
DIFF: 
https://github.com/llvm/llvm-project/commit/5ae881f96f999aaca98d8f83d3f00e037c783647.diff

LOG: [Docs] Repurpose 'sources' page as 'contributing'.

The page describing how to get the sources was more about contributing
to LLDB than getting the actual source. This patch moves some things
around and repurposes this page as a contributing to LLDB landing page.

Added: 
lldb/docs/resources/contributing.rst

Modified: 
lldb/docs/.htaccess
lldb/docs/index.rst
lldb/docs/resources/build.rst

Removed: 
lldb/docs/resources/source.rst



diff  --git a/lldb/docs/.htaccess b/lldb/docs/.htaccess
index aa63b1e0468f..cc92b0a65cfa 100644
--- a/lldb/docs/.htaccess
+++ b/lldb/docs/.htaccess
@@ -6,6 +6,8 @@ Redirect 301 /goals.html https://lldb.llvm.org/status/goals.html
 Redirect 301 /lldb-gdb.html https://lldb.llvm.org/use/map.html
 Redirect 301 /projects.html https://lldb.llvm.org/status/projects.html
 Redirect 301 /remote.html https://lldb.llvm.org/use/remote.html
-Redirect 301 /source.html https://lldb.llvm.org/resources/source.html
+Redirect 301 /source.html https://lldb.llvm.org/resources/contributing.html
 Redirect 301 /tutorial.html https://lldb.llvm.org/use/tutorial.html
 Redirect 301 /varformats.html https://lldb.llvm.org/use/variable.html
+
+Redirect 301 /resources/source.html 
https://lldb.llvm.org/resources/contributing.html

diff  --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index faabed9c691a..b833821554b1 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -138,12 +138,12 @@ interesting areas to contribute to lldb.
:maxdepth: 1
:caption: Resources
 
-   resources/download
-   resources/source
+   resources/contributing
resources/build
resources/test
resources/bots
resources/sbapi
+   resources/download
 
 .. toctree::
:hidden:

diff  --git a/lldb/docs/resources/build.rst b/lldb/docs/resources/build.rst
index ec938f41e21c..dabd224feff5 100644
--- a/lldb/docs/resources/build.rst
+++ b/lldb/docs/resources/build.rst
@@ -1,9 +1,19 @@
-Build
-=
+Building
+
 
 .. contents::
:local:
 
+Getting the Sources
+---
+
+Please refer to the `LLVM Getting Started Guide
+`_ for
+general instructions on how to check out the LLVM monorepo, which contains the
+LLDB sources.
+
+Git browser: https://github.com/llvm/llvm-project/tree/master/lldb
+
 Preliminaries
 -
 

diff  --git a/lldb/docs/resources/source.rst 
b/lldb/docs/resources/contributing.rst
similarity index 77%
rename from lldb/docs/resources/source.rst
rename to lldb/docs/resources/contributing.rst
index 0216d30d5c06..4305cdcaaf44 100644
--- a/lldb/docs/resources/source.rst
+++ b/lldb/docs/resources/contributing.rst
@@ -1,17 +1,14 @@
-Getting the Sources
-===
+Contributing
+
 
-Refer to the `LLVM Getting Started Guide
-`_
-for general instructions on how to check out source. Note that LLDB
-depends on having a working checkout of LLVM and Clang, so the first
-step is to download and build as described at the above URL. The same
-repository also contains LLDB.
+Getting Started
+---
 
-Git browser: https://github.com/llvm/llvm-project/tree/master/lldb
-
-Refer to the `Build Instructions `_ for more detailed instructions
-on how to build for a particular platform / build system combination.
+Please refer to the `LLVM Getting Started Guide
+`_ for general information on how to
+get started on the LLVM project. A detailed explanation on how to build and
+test LLDB can be found in the `build instructions `_ and `test
+instructions `_ respecitvely.
 
 Contributing to LLDB
 
@@ -21,10 +18,16 @@ Please refer to the `LLVM Developer Policy
 authoring and uploading a patch. LLDB 
diff ers from the LLVM Developer
 Policy in the following respects.
 
-Test infrastructure. It is still important to submit tests with your
-patches, but LLDB uses a 
diff erent system for tests. Refer to the
-`lldb/test` folder on disk for examples of how to write tests.  For
-anything not explicitly listed here, assume that LLDB follows the LLVM
+ - **Test infrastructure**: Like LLVM it is  important to submit tests with 
your
+   patches, but note that LLDB uses a 
diff erent system for tests. Refer to the
+   `test documentation `_ for more details and the `lldb/test`
+   folder on disk for examples.
+
+ - **Coding Style**: LLDB's code style 
diff ers from LLVM's coding style.
+   Unfortunately there is no document describing the 
diff erent. Please be
+   consistent with th

[Lldb-commits] [PATCH] D69523: [debugserver] Detect arch from LLVM_DEFAULT_TARGET_TRIPLE

2019-10-28 Thread Davide Italiano via Phabricator via lldb-commits

davide accepted this revision.
davide added a comment.
This revision is now accepted and ready to land.

LGTM


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69523/new/

https://reviews.llvm.org/D69523



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

[Lldb-commits] [PATCH] D68961: Add support for DW_AT_export_symbols for anonymous structs

2019-10-28 Thread Shafik Yaghmour via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGde2c7cab715e: Add support for DW_AT_export_symbols for 
anonymous structs (authored by shafik).
Herald added a project: LLDB.

Changed prior to commit:
  https://reviews.llvm.org/D68961?vs=226450&id=226764#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68961/new/

https://reviews.llvm.org/D68961

Files:
  lldb/include/lldb/Symbol/ClangASTContext.h
  lldb/packages/Python/lldbsuite/test/python_api/type/TestTypeList.py
  lldb/packages/Python/lldbsuite/test/python_api/type/main.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
  lldb/source/Symbol/ClangASTContext.cpp
  lldb/test/Shell/SymbolFile/DWARF/anon_class_w_and_wo_export_symbols.ll
  
lldb/test/Shell/SymbolFile/DWARF/clang-ast-from-dwarf-unamed-and-anon-structs.cpp

Index: lldb/test/Shell/SymbolFile/DWARF/clang-ast-from-dwarf-unamed-and-anon-structs.cpp
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/clang-ast-from-dwarf-unamed-and-anon-structs.cpp
@@ -0,0 +1,19 @@
+// Test to verify we are corectly generating anonymous flags when parsing
+// anonymous class and unnamed structs from DWARF to the a clang AST node.
+
+// RUN: %clang++ -g -c -o %t.o %s
+// RUN: lldb-test symbols -dump-clang-ast %t.o | FileCheck %s
+
+struct A {
+  struct {
+int x;
+  };
+  struct {
+int y;
+  } C;
+} a;
+
+// CHECK: A::(anonymous struct)
+// CHECK: |-DefinitionData is_anonymous pass_in_registers aggregate standard_layout trivially_copyable pod trivial literal
+// CHECK: A::(anonymous struct)
+// CHECK: |-DefinitionData pass_in_registers aggregate standard_layout trivially_copyable pod trivial literal
Index: lldb/test/Shell/SymbolFile/DWARF/anon_class_w_and_wo_export_symbols.ll
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/anon_class_w_and_wo_export_symbols.ll
@@ -0,0 +1,77 @@
+; This test verifies that we do the right thing with DIFlagExportSymbols which is the new
+; behavioir and without the DIFlagExportSymbols which is the old behavior for the given
+; definitions below.
+;
+;```
+; struct A{
+;   struct {
+;int x;
+;   };
+;   struct {
+;int y;
+;   };
+;   struct {
+;int z;
+;   } unnamed;
+; } a;
+;```
+;
+; RUN: %clang++ -g -c -o %t.o %s
+; RUN: lldb-test symbols -dump-clang-ast %t.o | FileCheck %s
+; RUN: llvm-dwarfdump %t.o | FileCheck %s --check-prefix DWARFDUMP
+
+%struct.A = type { %struct.anon, %struct.anon.0, %struct.anon.1 }
+%struct.anon = type { i32 }
+%struct.anon.0 = type { i32 }
+%struct.anon.1 = type { i32 }
+
+@a = global %struct.A zeroinitializer, align 4, !dbg !0
+
+!llvm.module.flags = !{!21, !22}
+!llvm.dbg.cu = !{!2}
+!llvm.ident = !{!23}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "a", scope: !2, file: !3, line: 11, type: !6, isLocal: false, isDefinition: true)
+!2 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !3, producer: "clang version 10.0.0", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !4, globals: !5, nameTableKind: None)
+!3 = !DIFile(filename: "anon_old_new.cpp", directory: "/dir")
+!4 = !{}
+!5 = !{!0}
+!6 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "A", file: !3, line: 1, size: 96, flags: DIFlagTypePassByValue, elements: !7, identifier: "_ZTS1A")
+; CHECK: struct A definition
+!7 = !{!8, !13, !17}
+!8 = !DIDerivedType(tag: DW_TAG_member, scope: !6, file: !3, line: 2, baseType: !9, size: 32)
+!9 = distinct !DICompositeType(tag: DW_TAG_structure_type, scope: !6, file: !3, line: 2, size: 32, flags: DIFlagExportSymbols | DIFlagTypePassByValue, elements: !10, identifier: "_ZTSN1AUt_E")
+; Correctly identify an anonymous class with DIFlagExportSymbols
+; CHECK: struct definition
+; CHECK: DefinitionData is_anonymous pass_in_registers aggregate standard_layout trivially_copyable pod trivial literal
+!10 = !{!11}
+!11 = !DIDerivedType(tag: DW_TAG_member, name: "x", scope: !9, file: !3, line: 3, baseType: !12, size: 32)
+!12 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!13 = !DIDerivedType(tag: DW_TAG_member, scope: !6, file: !3, line: 5, baseType: !14, size: 32, offset: 32)
+!14 = distinct !DICompositeType(tag: DW_TAG_structure_type, scope: !6, file: !3, line: 5, size: 32, flags: DIFlagTypePassByValue, elements: !15, identifier: "_ZTSN1AUt0_E")
+; Correctly identify an anonymous class without DIFlagExportSymbols
+; This works b/c we have additional checks when we fields to A.
+; CHECK: struct definition
+; CHECK: DefinitionData is_anonymous pass_in_registers aggregate standard_layout trivially_copyable pod trivial literal
+!15 = !{!16}
+!16 = !DIDerivedType(tag: DW_TAG_member, name: "y", scope: !14, file: !3, line: 6, ba

[Lldb-commits] [lldb] 82d3ba8 - [debugserver] Detect arch from LLVM_DEFAULT_TARGET_TRIPLE

2019-10-28 Thread Vedant Kumar via lldb-commits


Author: Vedant Kumar
Date: 2019-10-28T15:34:39-07:00
New Revision: 82d3ba87d06f9e2abc6e27d8799587d433c56630

URL: 
https://github.com/llvm/llvm-project/commit/82d3ba87d06f9e2abc6e27d8799587d433c56630
DIFF: 
https://github.com/llvm/llvm-project/commit/82d3ba87d06f9e2abc6e27d8799587d433c56630.diff

LOG: [debugserver] Detect arch from LLVM_DEFAULT_TARGET_TRIPLE

The debugserver build needs to conditionally include files depending on the
target architecture.

Switch on the architecture specified by LLVM_DEFAULT_TARGET_TRIPLE, as
the llvm and swift build systems use this variable to identify the
target (the latter, indirectly, through LLVM_HOST_TRIPLE).

It would be possible to switch on CMAKE_OSX_ARCHITECTURES, but the swift
build does not provide it, preferring instead to pass arch-specific
CFLAGS etc explicitly. Switching on LLVM_HOST_TRIPLE is also an option,
but it breaks down when cross-compiling.

Differential Revision: https://reviews.llvm.org/D69523

Added: 


Modified: 
lldb/tools/debugserver/source/MacOSX/CMakeLists.txt

Removed: 




diff  --git a/lldb/tools/debugserver/source/MacOSX/CMakeLists.txt 
b/lldb/tools/debugserver/source/MacOSX/CMakeLists.txt
index 7ad4a06a4d36..6d8e1ee449e3 100644
--- a/lldb/tools/debugserver/source/MacOSX/CMakeLists.txt
+++ b/lldb/tools/debugserver/source/MacOSX/CMakeLists.txt
@@ -1,14 +1,28 @@
-if("${CMAKE_OSX_ARCHITECTURES}" MATCHES ".*arm.*")
+# The debugserver build needs to conditionally include files depending on the
+# target architecture.
+#
+# Switch on the architecture specified by LLVM_DEFAULT_TARGET_TRIPLE, as
+# the llvm and swift build systems use this variable to identify the
+# target (the latter, indirectly, through LLVM_HOST_TRIPLE).
+#
+# It would be possible to switch on CMAKE_OSX_ARCHITECTURES, but the swift
+# build does not provide it, preferring instead to pass arch-specific
+# CFLAGS etc explicitly. Switching on LLVM_HOST_TRIPLE is also an option,
+# but it breaks down when cross-compiling.
+
+string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH 
${LLVM_DEFAULT_TARGET_TRIPLE})
+
+if("${LLDB_DEBUGSERVER_ARCH}" MATCHES ".*arm.*")
   list(APPEND SOURCES arm/DNBArchImpl.cpp arm64/DNBArchImplARM64.cpp)
   include_directories(${CURRENT_SOURCE_DIR}/arm ${CURRENT_SOURCE_DIR}/arm64)
 endif()
 
-if(NOT CMAKE_OSX_ARCHITECTURES OR "${CMAKE_OSX_ARCHITECTURES}" MATCHES 
".*86.*")
+if(NOT LLDB_DEBUGSERVER_ARCH OR "${LLDB_DEBUGSERVER_ARCH}" MATCHES ".*86.*")
   list(APPEND SOURCES i386/DNBArchImplI386.cpp x86_64/DNBArchImplX86_64.cpp)
   include_directories(${CURRENT_SOURCE_DIR}/i386 ${CURRENT_SOURCE_DIR}/x86_64)
 endif()
 
-if("${CMAKE_OSX_ARCHITECTURES}" MATCHES ".*ppc.*")
+if("${LLDB_DEBUGSERVER_ARCH}" MATCHES ".*ppc.*")
   list(APPEND SOURCES ppc/DNBArchImpl.cpp)
   include_directories(${CURRENT_SOURCE_DIR}/ppc)
 endif()



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

[Lldb-commits] [PATCH] D69535: build: improve python check for Windows

2019-10-28 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

I proposed this in https://reviews.llvm.org/D64881 and the consensus was that 
we didn't want to do this.

Also I don't think this should be a Windows-only thing.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69535/new/

https://reviews.llvm.org/D69535



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

[Lldb-commits] [PATCH] D69453: Modernize TestThreadStepOut.py

2019-10-28 Thread Jim Ingham via Phabricator via lldb-commits

jingham updated this revision to Diff 226772.
jingham added a comment.

Addressed review comments.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69453/new/

https://reviews.llvm.org/D69453

Files:
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py
  lldb/packages/Python/lldbsuite/test/lldbutil.py

Index: lldb/packages/Python/lldbsuite/test/lldbutil.py
===
--- lldb/packages/Python/lldbsuite/test/lldbutil.py
+++ lldb/packages/Python/lldbsuite/test/lldbutil.py
@@ -760,7 +760,7 @@
 test.assertTrue(target, "Target: %s is not valid."%(exe_name))
 return target
 
-def run_to_breakpoint_do_run(test, target, bkpt, launch_info = None):
+def run_to_breakpoint_do_run(test, target, bkpt, launch_info = None, only_one_thread = True):
 
 # Launch the process, and do not stop at the entry point.
 if not launch_info:
@@ -778,14 +778,20 @@
 threads = get_threads_stopped_at_breakpoint(
 process, bkpt)
 
-test.assertTrue(len(threads) == 1, "Expected 1 thread to stop at breakpoint, %d did."%(len(threads)))
+num_threads = len(threads)
+if only_one_thread:
+test.assertEqual(num_threads, 1, "Expected 1 thread to stop at breakpoint, %d did."%(num_threads))
+else:
+test.assertGreater(num_threads, 0, "No threads stopped at breakpoint")
+
 thread = threads[0]
 return (target, process, thread, bkpt)
 
 def run_to_name_breakpoint (test, bkpt_name, launch_info = None,
 exe_name = "a.out",
 bkpt_module = None,
-in_cwd = True):
+in_cwd = True,
+only_one_thread = True):
 """Start up a target, using exe_name as the executable, and run it to
a breakpoint set by name on bkpt_name restricted to bkpt_module.
 
@@ -807,6 +813,11 @@
If successful it returns a tuple with the target process and
thread that hit the breakpoint, and the breakpoint that we set
for you.
+
+   If only_one_thread is true, we require that there be only one
+   thread stopped at the breakpoint.  Otherwise we only require one
+   or more threads stop there.  If there are more than one, we return
+   the first thread that stopped.
 """
 
 target = run_to_breakpoint_make_target(test, exe_name, in_cwd)
@@ -816,12 +827,13 @@
 
 test.assertTrue(breakpoint.GetNumLocations() > 0,
 "No locations found for name breakpoint: '%s'."%(bkpt_name))
-return run_to_breakpoint_do_run(test, target, breakpoint, launch_info)
+return run_to_breakpoint_do_run(test, target, breakpoint, launch_info, only_one_thread)
 
 def run_to_source_breakpoint(test, bkpt_pattern, source_spec,
  launch_info = None, exe_name = "a.out",
  bkpt_module = None,
- in_cwd = True):
+ in_cwd = True,
+ only_one_thread = True):
 """Start up a target, using exe_name as the executable, and run it to
a breakpoint set by source regex bkpt_pattern.
 
@@ -835,12 +847,13 @@
 test.assertTrue(breakpoint.GetNumLocations() > 0,
 'No locations found for source breakpoint: "%s", file: "%s", dir: "%s"'
 %(bkpt_pattern, source_spec.GetFilename(), source_spec.GetDirectory()))
-return run_to_breakpoint_do_run(test, target, breakpoint, launch_info)
+return run_to_breakpoint_do_run(test, target, breakpoint, launch_info, only_one_thread)
 
 def run_to_line_breakpoint(test, source_spec, line_number, column = 0,
launch_info = None, exe_name = "a.out",
bkpt_module = None,
-   in_cwd = True):
+   in_cwd = True,
+   only_one_thread = True):
 """Start up a target, using exe_name as the executable, and run it to
a breakpoint set by (source_spec, line_number(, column)).
 
@@ -855,7 +868,7 @@
 'No locations found for line breakpoint: "%s:%d(:%d)", dir: "%s"'
 %(source_spec.GetFilename(), line_number, column,
   source_spec.GetDirectory()))
-return run_to_breakpoint_do_run(test, target, breakpoint, launch_info)
+return run_to_breakpoint_do_run(test, target, breakpoint, launch_info, only_one_thread)
 
 
 def continue_to_breakpoint(process, bkpt):
Index: lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py
===
--- lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py
+++ lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py
@@ -68,7 +68,9 @@
 # Call super's setUp().
 TestBase.setU

[Lldb-commits] [PATCH] D69453: Modernize TestThreadStepOut.py

2019-10-28 Thread Jim Ingham via Phabricator via lldb-commits

jingham marked 4 inline comments as done.
jingham added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py:136
+(self.inferior_target, self.inferior_process, thread, bkpt) = 
lldbutil.run_to_source_breakpoint(
+self, self.bkpt_string, self.main_file, only_one_thread = False)
 

aprantl wrote:
> If `self.bkpt_string` and `self.main_file` are only used here, I would find 
> this easier to read:
> 
> `ldbutil.run_to_source_breakpoint(self, 'break here', 
> lldb.SBFileSpec('main.cpp'), only_one_thread = False)`
self.main_file is only used here, I moved it.

self.bkpt_string is used to calculate the line number self.breakpoint, and then 
the source breakpoint we set in run_to_source_breakpoint is supposed to match 
that line.  So I think it is clearer to use the variable than to repeat the 
pattern twice.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69453/new/

https://reviews.llvm.org/D69453



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

[Lldb-commits] [lldb] 651b5e7 - Modernize TestThreadStepOut.py

2019-10-28 Thread Jim Ingham via lldb-commits


Author: Jim Ingham
Date: 2019-10-28T16:15:09-07:00
New Revision: 651b5e725ee6812fdabb369ed2ecd4740106a82c

URL: 
https://github.com/llvm/llvm-project/commit/651b5e725ee6812fdabb369ed2ecd4740106a82c
DIFF: 
https://github.com/llvm/llvm-project/commit/651b5e725ee6812fdabb369ed2ecd4740106a82c.diff

LOG: Modernize TestThreadStepOut.py

This test was timing out on the swift CI bots.  I didn't see any obvious reason
for that, and the test hasn't had problems on greendragon.  OTOH, it was a bit
oddly written, and needed modernizing, so I did that.

Differential Revision: https://reviews.llvm.org/D69453

Added: 


Modified: 

lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py
lldb/packages/Python/lldbsuite/test/lldbutil.py

Removed: 




diff  --git 
a/lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py
 
b/lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py
index 866f2152151c..80680768e3ca 100644
--- 
a/lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py
+++ 
b/lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py
@@ -68,7 +68,9 @@ def setUp(self):
 # Call super's setUp().
 TestBase.setUp(self)
 # Find the line number for our breakpoint.
-self.breakpoint = line_number('main.cpp', '// Set breakpoint here')
+self.bkpt_string = '// Set breakpoint here'
+self.breakpoint = line_number('main.cpp', self.bkpt_string)   
+
 if "gcc" in self.getCompiler() or self.isIntelCompiler():
 self.step_out_destination = line_number(
 'main.cpp', '// Expect to stop here after step-out (icc and 
gcc)')
@@ -129,56 +131,27 @@ def step_out_with_python(self):
 
 def step_out_test(self, step_out_func):
 """Test single thread step out of a function."""
-exe = self.getBuildArtifact("a.out")
-self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
-
-# This should create a breakpoint in the main thread.
-lldbutil.run_break_set_by_file_and_line(
-self, "main.cpp", self.breakpoint, num_expected_locations=1)
-
-# The breakpoint list should show 1 location.
-self.expect(
-"breakpoint list -f",
-"Breakpoint location shown correctly",
-substrs=[
-"1: file = 'main.cpp', line = %d, exact_match = 0, locations = 
1" %
-self.breakpoint])
+(self.inferior_target, self.inferior_process, thread, bkpt) = 
lldbutil.run_to_source_breakpoint(
+self, self.bkpt_string, lldb.SBFileSpec('main.cpp'), 
only_one_thread = False)
 
-# Run the program.
-self.runCmd("run", RUN_SUCCEEDED)
-
-# Get the target process
-self.inferior_target = self.dbg.GetSelectedTarget()
-self.inferior_process = self.inferior_target.GetProcess()
-
-# Get the number of threads, ensure we see all three.
-num_threads = self.inferior_process.GetNumThreads()
-self.assertEqual(
-num_threads,
-3,
-'Number of expected threads and actual threads do not match.')
+# We hit the breakpoint on at least one thread.  If we hit it on both 
threads
+# simultaneously, we can try the step out.  Otherwise, suspend the 
thread
+# that hit the breakpoint, and continue till the second thread hits
+# the breakpoint:
 
 (breakpoint_threads, other_threads) = ([], [])
 lldbutil.sort_stopped_threads(self.inferior_process,
   breakpoint_threads=breakpoint_threads,
   other_threads=other_threads)
-
-while len(breakpoint_threads) < 2:
-self.runCmd("thread continue %s" %
-" ".join([str(x.GetIndexID()) for x in other_threads]))
-lldbutil.sort_stopped_threads(
-self.inferior_process,
-breakpoint_threads=breakpoint_threads,
-other_threads=other_threads)
+if len(breakpoint_threads) == 1:
+success = thread.Suspend()
+self.assertTrue(success, "Couldn't suspend a thread")
+bkpt_threads = lldbutil.continue_to_breakpoint(bkpt)
+self.assertEqual(len(bkpt_threads), 1, "Second thread stopped")
+success = thread.Resume()
+self.assertTrue(success, "Couldn't resume a thread")
 
 self.step_out_thread = breakpoint_threads[0]
 
 # Step out of thread stopped at breakpoint
 step_out_func()
-
-# Run to completion
-self.runCmd("continue")
-
-# At this point, the inferior process should have exited.
-self.assertTrue(self.inferior_process.GetState() ==
-lldb.eS

[Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

2019-10-28 Thread Guilherme Andrade via Phabricator via lldb-commits

guiandrade updated this revision to Diff 226778.
guiandrade added a comment.

Adding tests


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62931/new/

https://reviews.llvm.org/D62931

Files:
  
lldb/packages/Python/lldbsuite/test/commands/register/register/intel_xtended_registers/mpx_offset_intersection/Makefile
  
lldb/packages/Python/lldbsuite/test/commands/register/register/intel_xtended_registers/mpx_offset_intersection/TestMPXOffsetIntersection.py
  
lldb/packages/Python/lldbsuite/test/commands/register/register/intel_xtended_registers/mpx_offset_intersection/main.cpp
  
lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestGDBRemoteClient.py
  
lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.h
  lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemoteProperties.td
  lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
  lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp

Index: lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
===
--- lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
+++ lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
@@ -128,6 +128,11 @@
   ASSERT_EQ(0,
 memcmp(buffer_sp->GetBytes(), one_register, sizeof one_register));
 
+  async_result = std::async(std::launch::async,
+[&] { return client.GetgPacketSupported(tid); });
+  HandlePacket(server, "g;thread:0047;", all_registers_hex);
+  ASSERT_TRUE(async_result.get());
+
   read_result = std::async(std::launch::async,
[&] { return client.ReadAllRegisters(tid); });
   HandlePacket(server, "g;thread:0047;", all_registers_hex);
Index: lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
+++ lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
@@ -301,13 +301,15 @@
 if (process_sp) {
   ProcessGDBRemote *gdb_process =
   static_cast(process_sp.get());
-  // read_all_registers_at_once will be true if 'p' packet is not
-  // supported.
   bool read_all_registers_at_once =
-  !gdb_process->GetGDBRemote().GetpPacketSupported(GetID());
+  gdb_process->GetGDBRemote().GetgPacketSupported(GetID()) &&
+  gdb_process->m_use_g_packet_for_reading;
+  bool write_all_registers_at_once =
+  gdb_process->GetGDBRemote().GetGPacketSupported(GetID()) &&
+  gdb_process->m_use_g_packet_for_writing;
   reg_ctx_sp = std::make_shared(
   *this, concrete_frame_idx, gdb_process->m_register_info,
-  read_all_registers_at_once);
+  read_all_registers_at_once, write_all_registers_at_once);
 }
   } else {
 Unwind *unwinder = GetUnwinder();
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemoteProperties.td
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemoteProperties.td
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemoteProperties.td
@@ -13,4 +13,12 @@
 Global,
 DefaultFalse,
 Desc<"If true, the libraries-svr4 feature will be used to get a hold of the process's loaded modules.">;
+  def UseGPacketForReading: Property<"use-g-packet-for-reading", "Boolean">,
+Global,
+DefaultTrue,
+Desc<"Specify if the server should use 'g' packets to read registers.">;
+  def UseGPacketForWriting: Property<"use-g-packet-for-writing", "Boolean">,
+Global,
+DefaultFalse,
+Desc<"Specify if the server should use 'G' packets to write registers.">;
 }
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -284,6 +284,8 @@
   lldb::CommandObjectSP m_command_sp;
   int64_t m_breakpoint_pc_offset;
   lldb::tid_t m_initial_tid; // The initial thread ID, given by stub on at

[Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

2019-10-28 Thread Guilherme Andrade via Phabricator via lldb-commits

guiandrade updated this revision to Diff 226779.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62931/new/

https://reviews.llvm.org/D62931

Files:
  
lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestGDBRemoteClient.py
  
lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemoteProperties.td
  lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
  lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp

Index: lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
===
--- lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
+++ lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
@@ -128,6 +128,11 @@
   ASSERT_EQ(0,
 memcmp(buffer_sp->GetBytes(), one_register, sizeof one_register));
 
+  async_result = std::async(std::launch::async,
+[&] { return client.GetgPacketSupported(tid); });
+  HandlePacket(server, "g;thread:0047;", all_registers_hex);
+  ASSERT_TRUE(async_result.get());
+
   read_result = std::async(std::launch::async,
[&] { return client.ReadAllRegisters(tid); });
   HandlePacket(server, "g;thread:0047;", all_registers_hex);
Index: lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
+++ lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
@@ -301,13 +301,15 @@
 if (process_sp) {
   ProcessGDBRemote *gdb_process =
   static_cast(process_sp.get());
-  // read_all_registers_at_once will be true if 'p' packet is not
-  // supported.
   bool read_all_registers_at_once =
-  !gdb_process->GetGDBRemote().GetpPacketSupported(GetID());
+  gdb_process->GetGDBRemote().GetgPacketSupported(GetID()) &&
+  gdb_process->m_use_g_packet_for_reading;
+  bool write_all_registers_at_once =
+  gdb_process->GetGDBRemote().GetGPacketSupported(GetID()) &&
+  gdb_process->m_use_g_packet_for_writing;
   reg_ctx_sp = std::make_shared(
   *this, concrete_frame_idx, gdb_process->m_register_info,
-  read_all_registers_at_once);
+  read_all_registers_at_once, write_all_registers_at_once);
 }
   } else {
 Unwind *unwinder = GetUnwinder();
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemoteProperties.td
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemoteProperties.td
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemoteProperties.td
@@ -13,4 +13,12 @@
 Global,
 DefaultFalse,
 Desc<"If true, the libraries-svr4 feature will be used to get a hold of the process's loaded modules.">;
+  def UseGPacketForReading: Property<"use-g-packet-for-reading", "Boolean">,
+Global,
+DefaultTrue,
+Desc<"Specify if the server should use 'g' packets to read registers.">;
+  def UseGPacketForWriting: Property<"use-g-packet-for-writing", "Boolean">,
+Global,
+DefaultFalse,
+Desc<"Specify if the server should use 'G' packets to write registers.">;
 }
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -284,6 +284,8 @@
   lldb::CommandObjectSP m_command_sp;
   int64_t m_breakpoint_pc_offset;
   lldb::tid_t m_initial_tid; // The initial thread ID, given by stub on attach
+  bool m_use_g_packet_for_reading;
+  bool m_use_g_packet_for_writing;
 
   bool m_replay_mode;
   bool m_allow_flash_writes;
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -154,6 +154,16 @@
 nullptr, idx,
 g_processgdbremote_properties[idx].default_uint_value != 0);
   }
+
+  bool GetUseGPacketForReading() const {
+const uint32_t idx = ePropertyUseGPacketForReading;
+return m_collection_sp->GetPropertyAtIndexAsBoolean(nullptr, idx, true);
+  }
+
+  bool GetUseGPacketForWriting() const {
+const uint32_t idx = ePr

[Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

2019-10-28 Thread Guilherme Andrade via Phabricator via lldb-commits

guiandrade marked an inline comment as done.
guiandrade added a comment.

In D62931#1719948 , @labath wrote:

> I'm sorry, this dropped off my radar. The code looks fine, but it could use 
> some more tests. For instance, one test when you set the setting value to the 
> non-default , and then check that lldb does _not_ use the `g` packet .

Yeah, more tests would be useful. They made me notice an issue btw. I was 
simply sending a 'g' packet and checking if the server replied back nicely; 
however, IIUC with 'G' packets it isn't so simple because we also need to send 
the registers data in the same packet. I'm not sure how I could do that, and 
I'm also afraid that check could get too expensive. Do you have any idea what 
could be a nice way to handle that?

Thank you!

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62931/new/

https://reviews.llvm.org/D62931

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

[Lldb-commits] [PATCH] D69019: [lldb] move package generation from python to cmake

2019-10-28 Thread Haibo Huang via Phabricator via lldb-commits

hhb updated this revision to Diff 226781.
hhb added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69019/new/

https://reviews.llvm.org/D69019

Files:
  lldb/CMakeLists.txt
  lldb/scripts/Python/createPythonInit.py
  lldb/scripts/Python/finishSwigPythonLLDB.py
  lldb/scripts/finishSwigWrapperClasses.py
  lldb/scripts/utilsArgsParse.py
  lldb/scripts/utilsDebug.py
  lldb/scripts/utilsOsType.py

Index: lldb/scripts/utilsOsType.py
===
--- lldb/scripts/utilsOsType.py
+++ /dev/null
@@ -1,103 +0,0 @@
-""" Utility module to determine the OS Python running on
-
---
-File: utilsOsType.py
-
-Overview:   Python module to supply functions and an enumeration to
-help determine the platform type, bit size and OS currently
-being used.
---
-
-"""
-
-# Python modules:
-import sys  # Provide system information
-
-# Third party modules:
-
-# In-house modules:
-
-# Instantiations:
-
-# Enumerations:
-#-
-# Details:  Class to implement a 'C' style enumeration type.
-# Gotchas:  None.
-# Authors:  Illya Rudkin 28/11/2013.
-# Changes:  None.
-#--
-if sys.version_info.major >= 3:
-from enum import Enum
-
-class EnumOsType(Enum):
-Unknown = 0
-Darwin = 1
-FreeBSD = 2
-Linux = 3
-NetBSD = 4
-OpenBSD = 5
-Windows = 6
-kFreeBSD = 7
-else:
-class EnumOsType(object):
-values = ["Unknown",
-  "Darwin",
-  "FreeBSD",
-  "Linux",
-  "NetBSD",
-  "OpenBSD",
-  "Windows",
-  "kFreeBSD"]
-
-class __metaclass__(type):
-#++
-# Details:  Fn acts as an enumeration.
-# Args: vName - (R) Enumeration to match.
-# Returns:  Int - Matching enumeration/index.
-# Throws:   None.
-#--
-
-def __getattr__(cls, vName):
-return cls.values.index(vName)
-
-#++---
-# Details:  Reverse fast lookup of the values list.
-# Args: vI - (R) Index / enumeration.
-# Returns:  Str - text description matching enumeration.
-# Throws:   None.
-#--
-def name_of(cls, vI):
-return EnumOsType.values[vI]
-
-#-
-#-
-#-
-
-#++---
-# Details:  Determine what operating system is currently running on.
-# Args: None.
-# Returns:  EnumOsType - The OS type being used ATM.
-# Throws:   None.
-#--
-
-
-def determine_os_type():
-eOSType = EnumOsType.Unknown
-
-strOS = sys.platform
-if strOS == "darwin":
-eOSType = EnumOsType.Darwin
-elif strOS.startswith("freebsd"):
-eOSType = EnumOsType.FreeBSD
-elif strOS.startswith("linux"):
-eOSType = EnumOsType.Linux
-elif strOS.startswith("netbsd"):
-eOSType = EnumOsType.NetBSD
-elif strOS.startswith("openbsd"):
-eOSType = EnumOsType.OpenBSD
-elif strOS == "win32":
-eOSType = EnumOsType.Windows
-elif strOS.startswith("gnukfreebsd"):
-eOSType = EnumOsType.kFreeBSD
-
-return eOSType
Index: lldb/scripts/utilsDebug.py
===
--- lldb/scripts/utilsDebug.py
+++ /dev/null
@@ -1,125 +0,0 @@
-""" Utility module to help debug Python scripts
-
---
-File: utilsDebug.py
-
-Overview:  Python module to supply functions to help debug Python
-   scripts.
-Gotchas:   None.
-Copyright: None.
---
-"""
-
-# Python modules:
-import sys
-
-# Third party modules:
-
-# In-house modules:
-
-# Instantiations:
-
-#-
-# Details: Class to implement simple stack function trace. Instantiation the
-#  class as the first function you want to trace. Example:
-#  obj = utilsDebug.CDebugFnVerbose("validate_arguments()")
-# Gotchas: This class will not work in properly in a multi-threaded
-#  environment.
-# Authors: Illya Rudkin 28/11/2013.
-# Changes: None.
-#--
-
-
-class CD

[Lldb-commits] [PATCH] D69523: [debugserver] Detect arch from LLVM_DEFAULT_TARGET_TRIPLE

2019-10-28 Thread Vedant Kumar via Phabricator via lldb-commits

vsk closed this revision.
vsk added a comment.

Landed in 82d3ba.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69523/new/

https://reviews.llvm.org/D69523



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

[Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

2019-10-28 Thread Jason Molenda via Phabricator via lldb-commits

jasonmolenda added a comment.

In D62931#1724433 , @guiandrade wrote:

> Yeah, more tests would be useful. They made me notice an issue btw. I was 
> simply sending a 'g' packet and checking if the server replied back nicely; 
> however, IIUC with 'G' packets it isn't so simple because we also need to 
> send the registers data in the same packet. I'm not sure how I could do that, 
> and I'm also afraid that check could get too expensive. Do you have any idea 
> what could be a nice way to handle that?


fwiw I can't imagine a stub that supports g but not G.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62931/new/

https://reviews.llvm.org/D62931



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

[Lldb-commits] [PATCH] D69453: Modernize TestThreadStepOut.py

2019-10-28 Thread Jim Ingham via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG651b5e725ee6: Modernize TestThreadStepOut.py (authored by 
jingham).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69453/new/

https://reviews.llvm.org/D69453

Files:
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py
  lldb/packages/Python/lldbsuite/test/lldbutil.py

Index: lldb/packages/Python/lldbsuite/test/lldbutil.py
===
--- lldb/packages/Python/lldbsuite/test/lldbutil.py
+++ lldb/packages/Python/lldbsuite/test/lldbutil.py
@@ -760,7 +760,7 @@
 test.assertTrue(target, "Target: %s is not valid."%(exe_name))
 return target
 
-def run_to_breakpoint_do_run(test, target, bkpt, launch_info = None):
+def run_to_breakpoint_do_run(test, target, bkpt, launch_info = None, only_one_thread = True):
 
 # Launch the process, and do not stop at the entry point.
 if not launch_info:
@@ -778,14 +778,20 @@
 threads = get_threads_stopped_at_breakpoint(
 process, bkpt)
 
-test.assertTrue(len(threads) == 1, "Expected 1 thread to stop at breakpoint, %d did."%(len(threads)))
+num_threads = len(threads)
+if only_one_thread:
+test.assertEqual(num_threads, 1, "Expected 1 thread to stop at breakpoint, %d did."%(num_threads))
+else:
+test.assertGreater(num_threads, 0, "No threads stopped at breakpoint")
+
 thread = threads[0]
 return (target, process, thread, bkpt)
 
 def run_to_name_breakpoint (test, bkpt_name, launch_info = None,
 exe_name = "a.out",
 bkpt_module = None,
-in_cwd = True):
+in_cwd = True,
+only_one_thread = True):
 """Start up a target, using exe_name as the executable, and run it to
a breakpoint set by name on bkpt_name restricted to bkpt_module.
 
@@ -807,6 +813,11 @@
If successful it returns a tuple with the target process and
thread that hit the breakpoint, and the breakpoint that we set
for you.
+
+   If only_one_thread is true, we require that there be only one
+   thread stopped at the breakpoint.  Otherwise we only require one
+   or more threads stop there.  If there are more than one, we return
+   the first thread that stopped.
 """
 
 target = run_to_breakpoint_make_target(test, exe_name, in_cwd)
@@ -816,12 +827,13 @@
 
 test.assertTrue(breakpoint.GetNumLocations() > 0,
 "No locations found for name breakpoint: '%s'."%(bkpt_name))
-return run_to_breakpoint_do_run(test, target, breakpoint, launch_info)
+return run_to_breakpoint_do_run(test, target, breakpoint, launch_info, only_one_thread)
 
 def run_to_source_breakpoint(test, bkpt_pattern, source_spec,
  launch_info = None, exe_name = "a.out",
  bkpt_module = None,
- in_cwd = True):
+ in_cwd = True,
+ only_one_thread = True):
 """Start up a target, using exe_name as the executable, and run it to
a breakpoint set by source regex bkpt_pattern.
 
@@ -835,12 +847,13 @@
 test.assertTrue(breakpoint.GetNumLocations() > 0,
 'No locations found for source breakpoint: "%s", file: "%s", dir: "%s"'
 %(bkpt_pattern, source_spec.GetFilename(), source_spec.GetDirectory()))
-return run_to_breakpoint_do_run(test, target, breakpoint, launch_info)
+return run_to_breakpoint_do_run(test, target, breakpoint, launch_info, only_one_thread)
 
 def run_to_line_breakpoint(test, source_spec, line_number, column = 0,
launch_info = None, exe_name = "a.out",
bkpt_module = None,
-   in_cwd = True):
+   in_cwd = True,
+   only_one_thread = True):
 """Start up a target, using exe_name as the executable, and run it to
a breakpoint set by (source_spec, line_number(, column)).
 
@@ -855,7 +868,7 @@
 'No locations found for line breakpoint: "%s:%d(:%d)", dir: "%s"'
 %(source_spec.GetFilename(), line_number, column,
   source_spec.GetDirectory()))
-return run_to_breakpoint_do_run(test, target, breakpoint, launch_info)
+return run_to_breakpoint_do_run(test, target, breakpoint, launch_info, only_one_thread)
 
 
 def continue_to_breakpoint(process, bkpt):
Index: lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py
===
--- lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py
+++ lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.p

[Lldb-commits] [PATCH] D69019: [lldb] move package generation from python to cmake

2019-10-28 Thread Haibo Huang via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG99046b873f7f: [lldb] move package generation from python to 
cmake (authored by hhb).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69019/new/

https://reviews.llvm.org/D69019

Files:
  lldb/CMakeLists.txt
  lldb/scripts/Python/createPythonInit.py
  lldb/scripts/Python/finishSwigPythonLLDB.py
  lldb/scripts/finishSwigWrapperClasses.py
  lldb/scripts/utilsArgsParse.py
  lldb/scripts/utilsDebug.py
  lldb/scripts/utilsOsType.py

Index: lldb/scripts/utilsOsType.py
===
--- lldb/scripts/utilsOsType.py
+++ /dev/null
@@ -1,103 +0,0 @@
-""" Utility module to determine the OS Python running on
-
---
-File: utilsOsType.py
-
-Overview:   Python module to supply functions and an enumeration to
-help determine the platform type, bit size and OS currently
-being used.
---
-
-"""
-
-# Python modules:
-import sys  # Provide system information
-
-# Third party modules:
-
-# In-house modules:
-
-# Instantiations:
-
-# Enumerations:
-#-
-# Details:  Class to implement a 'C' style enumeration type.
-# Gotchas:  None.
-# Authors:  Illya Rudkin 28/11/2013.
-# Changes:  None.
-#--
-if sys.version_info.major >= 3:
-from enum import Enum
-
-class EnumOsType(Enum):
-Unknown = 0
-Darwin = 1
-FreeBSD = 2
-Linux = 3
-NetBSD = 4
-OpenBSD = 5
-Windows = 6
-kFreeBSD = 7
-else:
-class EnumOsType(object):
-values = ["Unknown",
-  "Darwin",
-  "FreeBSD",
-  "Linux",
-  "NetBSD",
-  "OpenBSD",
-  "Windows",
-  "kFreeBSD"]
-
-class __metaclass__(type):
-#++
-# Details:  Fn acts as an enumeration.
-# Args: vName - (R) Enumeration to match.
-# Returns:  Int - Matching enumeration/index.
-# Throws:   None.
-#--
-
-def __getattr__(cls, vName):
-return cls.values.index(vName)
-
-#++---
-# Details:  Reverse fast lookup of the values list.
-# Args: vI - (R) Index / enumeration.
-# Returns:  Str - text description matching enumeration.
-# Throws:   None.
-#--
-def name_of(cls, vI):
-return EnumOsType.values[vI]
-
-#-
-#-
-#-
-
-#++---
-# Details:  Determine what operating system is currently running on.
-# Args: None.
-# Returns:  EnumOsType - The OS type being used ATM.
-# Throws:   None.
-#--
-
-
-def determine_os_type():
-eOSType = EnumOsType.Unknown
-
-strOS = sys.platform
-if strOS == "darwin":
-eOSType = EnumOsType.Darwin
-elif strOS.startswith("freebsd"):
-eOSType = EnumOsType.FreeBSD
-elif strOS.startswith("linux"):
-eOSType = EnumOsType.Linux
-elif strOS.startswith("netbsd"):
-eOSType = EnumOsType.NetBSD
-elif strOS.startswith("openbsd"):
-eOSType = EnumOsType.OpenBSD
-elif strOS == "win32":
-eOSType = EnumOsType.Windows
-elif strOS.startswith("gnukfreebsd"):
-eOSType = EnumOsType.kFreeBSD
-
-return eOSType
Index: lldb/scripts/utilsDebug.py
===
--- lldb/scripts/utilsDebug.py
+++ /dev/null
@@ -1,125 +0,0 @@
-""" Utility module to help debug Python scripts
-
---
-File: utilsDebug.py
-
-Overview:  Python module to supply functions to help debug Python
-   scripts.
-Gotchas:   None.
-Copyright: None.
---
-"""
-
-# Python modules:
-import sys
-
-# Third party modules:
-
-# In-house modules:
-
-# Instantiations:
-
-#-
-# Details: Class to implement simple stack function trace. Instantiation the
-#  class as the first function you want to trace. Example:
-#  obj = utilsDebug.CDebugFnVerbose("validate_arguments()")
-# Gotchas: This class will not work in properly in a multi-

[Lldb-commits] [PATCH] D69535: build: improve python check for Windows

2019-10-28 Thread Saleem Abdulrasool via Phabricator via lldb-commits

compnerd added a comment.

The reason for bringing this back up as a Windows specific thing is that 
currently, there is no good way to build LLDB with python support without 
having to specify additional details on *just* windows because the windows path 
is doing something special.  This is trying to bring the windows path to parity 
with the Linux path.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69535/new/

https://reviews.llvm.org/D69535



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

[Lldb-commits] [PATCH] D69488: [LLDB][Python] fix another fflush issue on NetBSD

2019-10-28 Thread Michał Górny via Phabricator via lldb-commits

mgorny added a comment.

Diff 4, I think. Lemme do a quick test with 5. Hopefully it won't request me to 
rebuild everything again.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69488/new/

https://reviews.llvm.org/D69488



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

[Lldb-commits] [PATCH] D69488: [LLDB][Python] fix another fflush issue on NetBSD

2019-10-28 Thread Michał Górny via Phabricator via lldb-commits

mgorny accepted this revision.
mgorny added a comment.
This revision is now accepted and ready to land.

WFM. Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69488/new/

https://reviews.llvm.org/D69488



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

57 matches

Mail list logo