[Lldb-commits] [lldb] r280697 - Fix build breakage in r280692

[Pavel Labath via lldb-commits]

Author: labath
Date: Tue Sep  6 05:04:22 2016
New Revision: 280697

URL: http://llvm.org/viewvc/llvm-project?rev=280697&view=rev
Log:
Fix build breakage in r280692

The commit introduced an array of const objects, which libstdc++ does not like. 
Make the object
non-const.

Also fix a compiler warning while I'm in there.

Modified:
lldb/trunk/include/lldb/Core/Disassembler.h
lldb/trunk/source/Target/Process.cpp
lldb/trunk/source/Target/StackFrame.cpp

Modified: lldb/trunk/include/lldb/Core/Disassembler.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Disassembler.h?rev=280697&r1=280696&r2=280697&view=diff
==
--- lldb/trunk/include/lldb/Core/Disassembler.h (original)
+++ lldb/trunk/include/lldb/Core/Disassembler.h Tue Sep  6 05:04:22 2016
@@ -193,7 +193,7 @@ public:
 Sum,
 Product
 } m_type = Type::Invalid;
-std::vector m_children;
+std::vector m_children;
 lldb::addr_t m_immediate = 0;
 ConstString m_register;
 bool m_negative = false;

Modified: lldb/trunk/source/Target/Process.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Process.cpp?rev=280697&r1=280696&r2=280697&view=diff
==
--- lldb/trunk/source/Target/Process.cpp (original)
+++ lldb/trunk/source/Target/Process.cpp Tue Sep  6 05:04:22 2016
@@ -1259,7 +1259,7 @@ Process::HandleProcessStateChangedEvent
 const ValueObject::GetExpressionPathFormat 
format = 
ValueObject::GetExpressionPathFormat::eGetExpressionPathFormatHonorPointers;
 stream->PutCString("Likely cause: ");
 valobj_sp->GetExpressionPath(*stream, 
qualify_cxx_base_classes, format);
-stream->Printf(" accessed 0x%llx\n", 
crashing_address);
+stream->Printf(" accessed 0x%" PRIx64 "\n", 
crashing_address);
 }
 }
 }

Modified: lldb/trunk/source/Target/StackFrame.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/StackFrame.cpp?rev=280697&r1=280696&r2=280697&view=diff
==
--- lldb/trunk/source/Target/StackFrame.cpp (original)
+++ lldb/trunk/source/Target/StackFrame.cpp Tue Sep  6 05:04:22 2016
@@ -1564,7 +1564,7 @@ namespace
 ValueObjectSP
 GetValueForOffset(StackFrame &frame, ValueObjectSP &parent, int64_t offset)
 {
-if (offset < 0 || offset >= parent->GetByteSize())
+if (offset < 0 || uint64_t(offset) >= parent->GetByteSize())
 {
 return ValueObjectSP();
 }


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

Re: [Lldb-commits] [lldb] r280692 - Added the "frame diagnose" command and use its output to make crash info better.

[Pavel Labath via lldb-commits]

On 6 September 2016 at 05:48, Sean Callanan via lldb-commits
 wrote:
> +
> +struct Operand
> +{
> +enum class Type {
> +Invalid = 0,
> +Register,
> +Immediate,
> +Dereference,
> +Sum,
> +Product
> +} m_type = Type::Invalid;
> +std::vector m_children;

Hi Sean,

this broke the build on linux, as libstdc++ fails to instantiate a
vector of const objects (I can't say I blame it). I've changed the
definition to non-const to make it build. Feel free to change if you
see a better way to handle that.



> +ValueObjectSP
> +GetValueForDereferincingOffset(StackFrame &frame, ValueObjectSP &base, 
> int64_t offset)
> +{
> +// base is a pointer to something
> +// offset is the thing to add to the pointer
> +// We return the most sensible ValueObject for the result of 
> *(base+offset)
> +
> +if (!base->IsPointerOrReferenceType())
> +{
> +return ValueObjectSP();
> +}
> +
> +Error error;
> +ValueObjectSP pointee = base->Dereference(error);
> +
> +if (offset >= pointee->GetByteSize())
I also noticed that the compiler is emitting a warning about
comparison of integers with different signs. Based on a cursory
examination I think this could be a genuine problem, but I have no
idea how to fix it. It would be great if you could look into that.


regards,
pavel
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r280703 - Revert "Intel(R) Memory Protection Extensions (Intel(R) MPX) support."

[Dimitar Vlahovski via lldb-commits]

Author: dvlahovski
Date: Tue Sep  6 06:00:37 2016
New Revision: 280703

URL: http://llvm.org/viewvc/llvm-project?rev=280703&view=rev
Log:
Revert "Intel(R) Memory Protection Extensions (Intel(R) MPX) support."

This reverts commit rL280668 because the register tests fail on i386
Linux.

I investigated a little bit what causes the failure - there are missing
registers when running 'register read -a'.
This is the output I got at the bottom:
"""
...
Memory Protection Extensions:
  bnd0 = {0x 0x}
  bnd1 = {0x 0x}
  bnd2 = {0x 0x}
  bnd3 = {0x 0x}

unknown:
2 registers were unavailable.
"""

Also looking at the packets exchanged between the client and server:
"""
...
history[308] tid=0x7338 <  19> send packet: $qRegisterInfo4a#d7
history[309] tid=0x7338 < 130> read packet:
$name:bnd0;bitsize:128;offset:1032;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:101;dwarf:101;#48
history[310] tid=0x7338 <  19> send packet: $qRegisterInfo4b#d8
history[311] tid=0x7338 < 130> read packet:
$name:bnd1;bitsize:128;offset:1048;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:102;dwarf:102;#52
history[312] tid=0x7338 <  19> send packet: $qRegisterInfo4c#d9
history[313] tid=0x7338 < 130> read packet:
$name:bnd2;bitsize:128;offset:1064;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:103;dwarf:103;#53
history[314] tid=0x7338 <  19> send packet: $qRegisterInfo4d#da
history[315] tid=0x7338 < 130> read packet:
$name:bnd3;bitsize:128;offset:1080;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:104;dwarf:104;#54
history[316] tid=0x7338 <  19> send packet: $qRegisterInfo4e#db
history[317] tid=0x7338 <  76> read packet:
$name:bndcfgu;bitsize:64;offset:1096;encoding:vector;format:vector-uint8;#99
history[318] tid=0x7338 <  19> send packet: $qRegisterInfo4f#dc
history[319] tid=0x7338 <  78> read packet:
$name:bndstatus;bitsize:64;offset:1104;encoding:vector;format:vector-uint8;#8e
...
"""

The bndcfgu and bndstatus registers don't have the 'Memory Protections
Extension' set. I looked at the code and it seems that that is set
correctly.

So I'm not sure what's the problem or where does it come from.

Also there is a second failure related to something like this in the
tests:
"""
registerSet.GetName().lower()
"""

For some reason the registerSet.GetName() returns None.

Added:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/Makefile
  - copied, changed from r280697, 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/register_command/Makefile

lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/TestRegisters.py
  - copied, changed from r280697, 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/register_command/TestRegisters.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/a.cpp
  - copied, changed from r280697, 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/register_command/a.cpp
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/main.cpp
  - copied, changed from r280697, 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/register_command/main.cpp
Removed:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/Makefile

lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/TestMPXRegisters.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp

lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/register_command/Makefile

lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/register_command/TestRegisters.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/register_command/a.cpp

lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/register_command/main.cpp
Modified:
lldb/trunk/source/Plugins/ABI/SysV-i386/ABISysV_i386.cpp
lldb/trunk/source/Plugins/ABI/SysV-x86_64/ABISysV_x86_64.cpp

lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.h
lldb/trunk/source/Plugins/Process/Utility/RegisterContext_x86.h
lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_i386.h
lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_x86_64.h
lldb/trunk/source/Plugins/Process/Utility/lldb-x86-register-enums.h

lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

Copied: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/Makefile 
(from r280697, 
lldb/trunk/packages/Python/ll

[Lldb-commits] [lldb] r280704 - Second round of fixups for r280692

[Pavel Labath via lldb-commits]

Author: labath
Date: Tue Sep  6 06:08:02 2016
New Revision: 280704

URL: http://llvm.org/viewvc/llvm-project?rev=280704&view=rev
Log:
Second round of fixups for r280692

Android targets don't have std::to_string and std::stoul. Use llvm::to_string 
and strtoul
instead.

Modified:
lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
lldb/trunk/source/Target/StopInfo.cpp

Modified: lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp?rev=280704&r1=280703&r2=280704&view=diff
==
--- lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp (original)
+++ lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp Tue Sep  
6 06:08:02 2016
@@ -25,6 +25,7 @@
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/TargetRegistry.h"
 #include "llvm/Support/TargetSelect.h"
+#include "llvm/Support/ScopedPrinter.h"
 
 // Other libraries and framework includes
 #include "DisassemblerLLVMC.h"
@@ -595,7 +596,7 @@ public:
 }
 else
 {
-ret.m_immediate = std::stoull(str, nullptr, 0);
+ret.m_immediate = strtoull(str.c_str(), nullptr, 0);
 return std::make_pair(ret, osi);
 }
 case 'x':
@@ -629,7 +630,7 @@ public:
 ++osi;
 }
 
-ret.m_immediate = std::stoull(str, nullptr, 0);
+ret.m_immediate = strtoull(str.c_str(), nullptr, 0);
 return std::make_pair(ret, osi);
 }
 
@@ -880,7 +881,7 @@ public:
 {
 s.PutCString("-");
 }
-s.PutCString(std::to_string(op.m_immediate).c_str());
+s.PutCString(llvm::to_string(op.m_immediate).c_str());
 break;
 case Operand::Type::Invalid:
 s.PutCString("Invalid");

Modified: lldb/trunk/source/Target/StopInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/StopInfo.cpp?rev=280704&r1=280703&r2=280704&view=diff
==
--- lldb/trunk/source/Target/StopInfo.cpp (original)
+++ lldb/trunk/source/Target/StopInfo.cpp Tue Sep  6 06:08:02 2016
@@ -1257,7 +1257,7 @@ StopInfo::GetCrashingDereference (StopIn
 
 address_loc += (sizeof(address_string) - 1);
 
-uint64_t address = std::stoull(address_loc, 0, 0);
+uint64_t address = strtoull(address_loc, 0, 0);
 if (crashing_address)
 {
 *crashing_address = address;


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

[Lldb-commits] [lldb] r280707 - Fixing an MSVC error from rL280692

[Dimitar Vlahovski via lldb-commits]

Author: dvlahovski
Date: Tue Sep  6 07:48:10 2016
New Revision: 280707

URL: http://llvm.org/viewvc/llvm-project?rev=280707&view=rev
Log:
Fixing an MSVC error from rL280692

MSVC emits an error when one uses a const variable in a lambda without
capturing it.

gcc and clang don't emit an error in this scenario.

Modified:
lldb/trunk/source/Commands/CommandObjectFrame.cpp

Modified: lldb/trunk/source/Commands/CommandObjectFrame.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectFrame.cpp?rev=280707&r1=280706&r2=280707&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectFrame.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectFrame.cpp Tue Sep  6 07:48:10 2016
@@ -218,7 +218,7 @@ protected:
 
 const bool qualify_cxx_base_classes = false;
 
-DumpValueObjectOptions::DeclPrintingHelper helper = 
[&valobj_sp](ConstString type,
+DumpValueObjectOptions::DeclPrintingHelper helper = [&valobj_sp, 
qualify_cxx_base_classes](ConstString type,
  
ConstString var,
  const 
DumpValueObjectOptions &opts,
  
Stream &stream) -> bool {


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

[Lldb-commits] [PATCH] D24255: Fix for rL280668, Intel(R) Memory Protection Extensions (Intel(R) MPX) support.

[Valentina Giusti via lldb-commits]

valentinagiusti created this revision.
valentinagiusti added a subscriber: lldb-commits.

Signed-off-by: Valentina Giusti 

https://reviews.llvm.org/D24255

Files:
  packages/Python/lldbsuite/test/functionalities/register/Makefile
  packages/Python/lldbsuite/test/functionalities/register/TestRegisters.py
  packages/Python/lldbsuite/test/functionalities/register/a.cpp
  
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/Makefile
  
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/TestMPXRegisters.py
  
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
  packages/Python/lldbsuite/test/functionalities/register/main.cpp
  
packages/Python/lldbsuite/test/functionalities/register/register_command/Makefile
  
packages/Python/lldbsuite/test/functionalities/register/register_command/TestRegisters.py
  packages/Python/lldbsuite/test/functionalities/register/register_command/a.cpp
  
packages/Python/lldbsuite/test/functionalities/register/register_command/main.cpp
  source/Plugins/ABI/SysV-i386/ABISysV_i386.cpp
  source/Plugins/ABI/SysV-x86_64/ABISysV_x86_64.cpp
  source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
  source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.h
  source/Plugins/Process/Utility/RegisterContext_x86.h
  source/Plugins/Process/Utility/RegisterInfos_i386.h
  source/Plugins/Process/Utility/RegisterInfos_x86_64.h
  source/Plugins/Process/Utility/lldb-x86-register-enums.h
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -610,6 +610,7 @@
   .Case("vector-sint32", eFormatVectorOfSInt32)
   .Case("vector-uint32", eFormatVectorOfUInt32)
   .Case("vector-float32", eFormatVectorOfFloat32)
+  .Case("vector-uint64", eFormatVectorOfUInt64)
   .Case("vector-uint128", eFormatVectorOfUInt128)
   .Default(eFormatInvalid);
 }
@@ -4545,6 +4546,8 @@
 reg_info.format = eFormatVectorOfUInt32;
 else if (value == "vector-float32")
 reg_info.format = eFormatVectorOfFloat32;
+else if (value == "vector-uint64")
+reg_info.format = eFormatVectorOfUInt64;
 else if (value == "vector-uint128")
 reg_info.format = eFormatVectorOfUInt128;
 }
Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1566,6 +1566,7 @@
 case eFormatVectorOfSInt32:  response.PutCString ("format:vector-sint32;"); break;
 case eFormatVectorOfUInt32:  response.PutCString ("format:vector-uint32;"); break;
 case eFormatVectorOfFloat32: response.PutCString ("format:vector-float32;"); break;
+case eFormatVectorOfUInt64:  response.PutCString ("format:vector-uint64;"); break;
 case eFormatVectorOfUInt128: response.PutCString ("format:vector-uint128;"); break;
 default: break;
 };
Index: source/Plugins/Process/Utility/lldb-x86-register-enums.h
===
--- source/Plugins/Process/Utility/lldb-x86-register-enums.h
+++ source/Plugins/Process/Utility/lldb-x86-register-enums.h
@@ -106,6 +106,18 @@
 lldb_ymm7_i386,
 k_last_avx_i386 = lldb_ymm7_i386,
 
+k_first_mpxr_i386,
+lldb_bnd0_i386 = k_first_mpxr_i386,
+lldb_bnd1_i386,
+lldb_bnd2_i386,
+lldb_bnd3_i386,
+k_last_mpxr = lldb_bnd3_i386,
+
+k_first_mpxc_i386,
+lldb_bndcfgu_i386 = k_first_mpxc_i386,
+lldb_bndstatus_i386,
+k_last_mpxc_i386 = lldb_bndstatus_i386,
+
 lldb_dr0_i386,
 lldb_dr1_i386,
 lldb_dr2_i386,
@@ -119,7 +131,8 @@
 k_num_gpr_registers_i386 = k_last_gpr_i386 - k_first_gpr_i386 + 1,
 k_num_fpr_registers_i386 = k_last_fpr_i386 - k_first_fpr_i386 + 1,
 k_num_avx_registers_i386 = k_last_avx_i386 - k_first_avx_i386 + 1,
-k_num_user_registers_i386 = k_num_gpr_registers_i386 + k_num_fpr_registers_i386 + k_num_avx_registers_i386,
+k_num_mpx_registers_i386 = k_last_mpxc_i386 - k_first_mpxr_i386 + 1,
+k_num_

Re: [Lldb-commits] [PATCH] D24255: Fix for rL280668, Intel(R) Memory Protection Extensions (Intel(R) MPX) support.

[Pavel Labath via lldb-commits]

labath requested changes to this revision.
labath added a comment.
This revision now requires changes to proceed.

I have a couple of questions I'd like to be answered before this goes in. Apart 
from the inline comments, all my questions from the previous version of this 
commit still stand.



Comment at: 
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/Makefile:5
@@ +4,3 @@
+
+ifeq "$(ARCH)" "i386"
+   CXXFLAGS += -mmpx -fcheck-pointer-bounds -fuse-ld=bfd -m32

This should not be necessary. Makefile.rules already correctly appends -m32 
when needed. Maybe CFLAGS_EXTRAS would work instead (?)


Comment at: 
packages/Python/lldbsuite/test/functionalities/register/register_command/TestRegisters.py:297
@@ -294,4 +296,3 @@
 for registerSet in registerSets:
-if 'advanced vector extensions' in 
registerSet.GetName().lower():
-has_avx = True
-break
+if registerSet.GetName():
+if 'advanced vector extensions' in 
registerSet.GetName().lower():

Do we want to allow a register set with no name? It looks like the root of the 
problem is elsewhere.


https://reviews.llvm.org/D24255



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

Re: [Lldb-commits] [PATCH] D24255: Fix for rL280668, Intel(R) Memory Protection Extensions (Intel(R) MPX) support.

[Zachary Turner via lldb-commits]

Also given that the reformat is going to happen today, I wonder if we
should wait until after it is complete to put in any more high risk changes.

On Tue, Sep 6, 2016 at 8:07 AM Pavel Labath via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> labath requested changes to this revision.
> labath added a comment.
> This revision now requires changes to proceed.
>
> I have a couple of questions I'd like to be answered before this goes in.
> Apart from the inline comments, all my questions from the previous version
> of this commit still stand.
>
>
> 
> Comment at:
> packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/Makefile:5
> @@ +4,3 @@
> +
> +ifeq "$(ARCH)" "i386"
> +   CXXFLAGS += -mmpx -fcheck-pointer-bounds -fuse-ld=bfd -m32
> 
> This should not be necessary. Makefile.rules already correctly appends
> -m32 when needed. Maybe CFLAGS_EXTRAS would work instead (?)
>
> 
> Comment at:
> packages/Python/lldbsuite/test/functionalities/register/register_command/TestRegisters.py:297
> @@ -294,4 +296,3 @@
>  for registerSet in registerSets:
> -if 'advanced vector extensions' in
> registerSet.GetName().lower():
> -has_avx = True
> -break
> +if registerSet.GetName():
> +if 'advanced vector extensions' in
> registerSet.GetName().lower():
> 
> Do we want to allow a register set with no name? It looks like the root of
> the problem is elsewhere.
>
>
> https://reviews.llvm.org/D24255
>
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D24187: Intel(R) Memory Protection Extensions (Intel(R) MPX) support.

[Valentina Giusti via lldb-commits]

valentinagiusti added a comment.

Thanks for the review! You can find my replies inline.



Comment at: 
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/TestMPXRegisters.py:27
@@ +26,3 @@
+
+@skipIfiOSSimulator
+@skipIf(compiler="clang")

labath wrote:
> Do we really need the ios simulator decorator here?
Is this naturally skipped if all OSs are skipped except for linux?


Comment at: 
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/TestMPXRegisters.py:29
@@ +28,3 @@
+@skipIf(compiler="clang")
+@expectedFailureAll(oslist=["linux"], compiler="gcc", 
compiler_version=["<", "5"])
+@skipIf(archs=no_match(['amd64', 'i386', 'x86_64']))

labath wrote:
> I presume this is XFAIL because the compiler does not have the required 
> features. If that is true then a "skip" result would be more appropriate.
True, here a skip would be better.


Comment at: 
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/TestMPXRegisters.py:30
@@ +29,3 @@
+@expectedFailureAll(oslist=["linux"], compiler="gcc", 
compiler_version=["<", "5"])
+@skipIf(archs=no_match(['amd64', 'i386', 'x86_64']))
+def test_mpx_registers_with_example_code(self):

labath wrote:
> It shouldn't be necessary to specify `amd64` here. I know some old code does 
> that, but now we have code in `lldbtest.py` which automatically remaps it to 
> `x86_64`.
ok, I'll remove it then!


Comment at: 
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/TestMPXRegisters.py:43
@@ +42,3 @@
+
+self.runCmd('settings set target.inline-breakpoint-strategy always')
+self.addTearDownHook(

labath wrote:
> Why is this necessary? (Also it looks like your cleanup function is the same 
> as the setup)
Sorry this is something I should have cleaned up.


Comment at: 
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/TestMPXRegisters.py:50
@@ +49,3 @@
+
+self.expect("thread backtrace", STOPPED_DUE_TO_BREAKPOINT,
+substrs = ["stop reason = breakpoint 1."])

labath wrote:
> So, this test will fail if run on hardware which does not have the registers 
> you are testing now (as far as I can tell, that's pretty much all of it). We 
> should detect that situation (the inferior already has code for that, 
> apparently), and skip the test. Something like:
> ```
> if inferior_exited_with_minus_1:
>   self.skipTest("blah blah")
> ```
> 
> 
Good point! I will add this


Repository:
  rL LLVM

https://reviews.llvm.org/D24187



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

Re: [Lldb-commits] [PATCH] D24236: gdb-remote: Add jModulesInfo packet

[Pavel Labath via lldb-commits]

labath updated this revision to Diff 70409.
labath added a comment.

- fix a bug where we would mark all modules as invalid if communicating with a 
stub which does not support this packet
- extend the packet documentation about what to do when modules are not found 
and the server volunteering information


https://reviews.llvm.org/D24236

Files:
  docs/lldb-gdb-remote.txt
  include/lldb/Target/Process.h
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteModuleInfo.py
  source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.h
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  source/Utility/StringExtractorGDBRemote.cpp
  source/Utility/StringExtractorGDBRemote.h
  unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp

Index: unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
===
--- unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
+++ unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
@@ -19,6 +19,7 @@
 
 #include "Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h"
 #include "lldb/Core/DataBuffer.h"
+#include "lldb/Core/ModuleSpec.h"
 
 #include "llvm/ADT/ArrayRef.h"
 
@@ -182,3 +183,75 @@
 HandlePacket(server, "QSyncThreadState:0047;", "OK");
 ASSERT_TRUE(async_result.get());
 }
+
+TEST_F(GDBRemoteCommunicationClientTest, GetModulesInfo)
+{
+TestClient client;
+MockServer server;
+Connect(client, server);
+if (HasFailure())
+return;
+
+llvm::Triple triple("i386-pc-linux");
+
+// Empty list of module specs should not send any packets
+ASSERT_TRUE(client.GetModulesInfo({}, triple).empty());
+
+FileSpec file_specs[] = { FileSpec("/foo/bar.so", false), FileSpec("/foo/baz.so", false) };
+std::future> async_result =
+std::async(std::launch::async, [&] { return client.GetModulesInfo(file_specs, triple); });
+HandlePacket(server, "jModulesInfo:["
+ R"({"file":"/foo/bar.so","triple":"i386-pc-linux"},)"
+ R"({"file":"/foo/baz.so","triple":"i386-pc-linux"}])",
+ R"([{"uuid":"404142434445464748494a4b4c4d4e4f","triple":"i386-pc-linux",)"
+ R"("file_path":"/foo/bar.so","file_offset":0,"file_size":1234}]])");
+
+std::vector result = async_result.get();
+ASSERT_EQ(1u, result.size());
+EXPECT_EQ("/foo/bar.so", result[0].GetFileSpec().GetPath());
+EXPECT_EQ(triple, result[0].GetArchitecture().GetTriple());
+EXPECT_EQ(UUID("@ABCDEFGHIJKLMNO", 16), result[0].GetUUID());
+EXPECT_EQ(0u, result[0].GetObjectOffset());
+EXPECT_EQ(1234u, result[0].GetObjectSize());
+}
+
+TEST_F(GDBRemoteCommunicationClientTest, GetModulesInfoInvalidResponse)
+{
+TestClient client;
+MockServer server;
+Connect(client, server);
+if (HasFailure())
+return;
+
+llvm::Triple triple("i386-pc-linux");
+FileSpec file_spec("/foo/bar.so", false);
+
+const char *invalid_responses[] = {
+"OK", "E47", "[]", "[{}]]",
+// no UUID
+R"([{"triple":"i386-pc-linux",)"
+R"("file_path":"/foo/bar.so","file_offset":0,"file_size":1234}])",
+// no triple
+R"([{"uuid":"404142434445464748494a4b4c4d4e4f",)"
+R"("file_path":"/foo/bar.so","file_offset":0,"file_size":1234}])",
+// no file_path
+R"([{"uuid":"404142434445464748494a4b4c4d4e4f","triple":"i386-pc-linux",)"
+R"("file_offset":0,"file_size":1234}])", 
+// no file_offset
+R"([{"uuid":"404142434445464748494a4b4c4d4e4f","triple":"i386-pc-linux",)"
+R"("file_path":"/foo/bar.so","file_size":1234}])",
+// no file_size
+R"([{"uuid":"404142434445464748494a4b4c4d4e4f","triple":"i386-pc-linux",)"
+R"("file_path":"/foo/bar.so","file_offset":0}])",
+};
+
+for(const char *response: invalid_responses)
+{
+std::future> async_result =
+std::async(std::launch::async, [&] { return client.GetModulesInfo(file_spec, triple); });
+HandlePacket(server, R"(jModulesInfo:[{"file":"/foo/bar.so","triple":"i386-pc-linux"}])",
+ response);
+
+ASSERT_TRUE(async_result.get().empty());
+}
+}
Index: source/Utility/StringExtractorGDBRemote.h
===
--- source/Utility/StringExtractorGDBRemote.h
+++ source/Utility/StringExtractorGDBRemote.h
@@ -146,6 +146,7 @@
 eServerPacketType_qXfer_auxv_read,
 
 eServerPacketType_jSignalsInfo,
+eServerPacketType_jModulesInfo,
 
 eServerP

Re: [Lldb-commits] [PATCH] D24255: Fix for rL280668, Intel(R) Memory Protection Extensions (Intel(R) MPX) support.

[Valentina Giusti via lldb-commits]

valentinagiusti added a comment.

Hi, inline there are my other replies.



Comment at: 
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/Makefile:5
@@ +4,3 @@
+
+ifeq "$(ARCH)" "i386"
+   CXXFLAGS += -mmpx -fcheck-pointer-bounds -fuse-ld=bfd -m32

labath wrote:
> This should not be necessary. Makefile.rules already correctly appends -m32 
> when needed. Maybe CFLAGS_EXTRAS would work instead (?)
Unfortunately it doesn't append -m32 to all the instances when also a linker is 
needed in the build process. In fact, in the test logs it shows that only the 
first call of the g++ command has such a flag, and therefore the inferior code 
build ends with an error.
If there is a better way to do the same with CFLAGS_EXTRAS please let me know!



Comment at: 
packages/Python/lldbsuite/test/functionalities/register/register_command/TestRegisters.py:297
@@ -294,4 +296,3 @@
 for registerSet in registerSets:
-if 'advanced vector extensions' in 
registerSet.GetName().lower():
-has_avx = True
-break
+if registerSet.GetName():
+if 'advanced vector extensions' in 
registerSet.GetName().lower():

labath wrote:
> Do we want to allow a register set with no name? It looks like the root of 
> the problem is elsewhere.
These lines of code are just to detect if there are AVX or MPX register sets, 
so I don't think there is the need to do anything about nameless sets here. If 
you don't like this solution, I think an alternative is to just check if there 
are the register names that belong to one set or the other, it just takes a bit 
longer - or I could just look for the first register in the set.


https://reviews.llvm.org/D24255



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

Re: [Lldb-commits] [PATCH] D24236: gdb-remote: Add jModulesInfo packet

[Greg Clayton via lldb-commits]

clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.

Jason Molenda already has a packet that does multiple module infos. Is this 
change using his packet format? Look for "jGetLoadedDynamicLibrariesInfos". We 
should try to use the same format since this already exists.


https://reviews.llvm.org/D24236



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

Re: [Lldb-commits] [PATCH] D24251: LLDB: API for Permission of object file's sections

[Greg Clayton via lldb-commits]

clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.

Just add header doc and this is good to go.



Comment at: include/lldb/API/SBSection.h:74
@@ -73,1 +73,3 @@
 
+uint32_t
+GetPermissions () const;

I know not everything is documented, but we should document this new call to 
let users know that the uint32_t will return a mask of bits from 
lldb::Permissions.


https://reviews.llvm.org/D24251



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

Re: [Lldb-commits] [PATCH] D24236: gdb-remote: Add jModulesInfo packet

[Pavel Labath via lldb-commits]

labath added a reviewer: jasonmolenda.
labath added a comment.

Hm... I was not aware of that packet. It does not appear to be directly 
applicable to this situation, because it queries the module information by load 
address, whereas here I query by file path. Also my packet does not return the 
segment/section information.

However, the dynamic linker plugin does know about load addresses so it could 
possibly be made to work with that packet. I'll need to study this tomorrow to 
understand how is that packet used. Consistency sounds like a good thing here, 
although the packet does seem to be making a lot of mac-specific assumptions.


https://reviews.llvm.org/D24236



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

Re: [Lldb-commits] [PATCH] D24236: gdb-remote: Add jModulesInfo packet

[Greg Clayton via lldb-commits]

clayborg added a comment.

Just take a look and see if there is anything worth re-using. If there is too 
much mac specific stuff in there, then just use the one created, but be sure to 
make it your new format completely agnostic to any platform so it can work for 
anything. It is OK to include platform specific keys that might be needed if 
the format, just place them in an appropriate dictionary, like

"macos" : { "cputype" : 123, "cpusubtype" : 234 }

If you need info on all shared libraries though, why not just use the XML 
version that already exists?

  Error ProcessGDBRemote::GetLoadedModuleList (LoadedModuleInfoList & list);

This uses the "libraries-svr4" packet that gets XML for all shared libraries. 
Is there information missing in that format that you require?


https://reviews.llvm.org/D24236



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

Re: [Lldb-commits] [PATCH] D24255: Fix for rL280668, Intel(R) Memory Protection Extensions (Intel(R) MPX) support.

[Greg Clayton via lldb-commits]

clayborg requested changes to this revision.
clayborg added a comment.

Just switch to using CFLAGS_EXTRAS and LD_EXTRAS and this is good to go.



Comment at: 
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/Makefile:6-11
@@ +5,8 @@
+ifeq "$(ARCH)" "i386"
+   CXXFLAGS += -mmpx -fcheck-pointer-bounds -fuse-ld=bfd -m32
+   LDFLAGS += -mmpx -fcheck-pointer-bounds -fuse-ld=bfd -m32
+endif
+ifeq "$(ARCH)" "x86_64"
+   CXXFLAGS += -mmpx -fcheck-pointer-bounds -fuse-ld=bfd
+   LDFLAGS += -mmpx -fcheck-pointer-bounds -fuse-ld=bfd
+endif

It would be nice to not modify the CXXFLAGS or LDFLAGS directly. You should 
modify CFLAGS_EXTRAS and LD_EXTRAS. I am not sure if there is a 
CXXFLAGS_EXTRAS, but feel free to add it if you can't use CFLAGS_EXTRAS


https://reviews.llvm.org/D24255



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

[Lldb-commits] [lldb] r280721 - Updated .clang-format rules so bring LLDB in line with LLVM standards.

[Kate Stone via lldb-commits]

Author: kate
Date: Tue Sep  6 12:19:00 2016
New Revision: 280721

URL: http://llvm.org/viewvc/llvm-project?rev=280721&view=rev
Log:
Updated .clang-format rules so bring LLDB in line with LLVM standards.


Added:
lldb/trunk/packages/Python/lldbsuite/.clang-format
Modified:
lldb/trunk/.clang-format

Modified: lldb/trunk/.clang-format
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/.clang-format?rev=280721&r1=280720&r2=280721&view=diff
==
--- lldb/trunk/.clang-format (original)
+++ lldb/trunk/.clang-format Tue Sep  6 12:19:00 2016
@@ -1,9 +1 @@
 BasedOnStyle: LLVM
-IndentWidth: 4
-ColumnLimit: 120
-BreakBeforeBraces: Allman
-AlwaysBreakAfterReturnType: All
-AllowShortFunctionsOnASingleLine: Inline
-ConstructorInitializerAllOnOneLineOrOnePerLine: true
-IndentCaseLabels: true
-AccessModifierOffset: -4

Added: lldb/trunk/packages/Python/lldbsuite/.clang-format
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/.clang-format?rev=280721&view=auto
==
--- lldb/trunk/packages/Python/lldbsuite/.clang-format (added)
+++ lldb/trunk/packages/Python/lldbsuite/.clang-format Tue Sep  6 12:19:00 2016
@@ -0,0 +1,4 @@
+DisableFormat: true
+
+# Disabling formatting doesn't implicitly disable include sorting
+SortIncludes: false


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

[Lldb-commits] LLVM buildmaster will be restarted in few minutes

[Galina Kistanova via lldb-commits]

Hello everyone,

LLVM buildmaster will be restarted in few minutes.
Sorry for inconvenience.

Thanks

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

[Lldb-commits] [lldb] r280755 - Reorder FreeBSD Host.cpp #includes to fix build

[Ed Maste via lldb-commits]

Author: emaste
Date: Tue Sep  6 16:25:31 2016
New Revision: 280755

URL: http://llvm.org/viewvc/llvm-project?rev=280755&view=rev
Log:
Reorder FreeBSD Host.cpp #includes to fix build

Modified:
lldb/trunk/source/Host/freebsd/Host.cpp

Modified: lldb/trunk/source/Host/freebsd/Host.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/freebsd/Host.cpp?rev=280755&r1=280754&r2=280755&view=diff
==
--- lldb/trunk/source/Host/freebsd/Host.cpp (original)
+++ lldb/trunk/source/Host/freebsd/Host.cpp Tue Sep  6 16:25:31 2016
@@ -9,17 +9,19 @@
 
//===--===//
 
 // C Includes
-#include 
-#include 
-#include 
+#include 
+
+#include 
 #include 
+#include 
 #include 
-#include 
 #include 
 
 #include 
-#include 
-#include 
+
+#include 
+#include 
+#include 
 
 // C++ Includes
 // Other libraries and framework includes


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

[Lldb-commits] [lldb] r280757 - Make LLDB compile on Windows after the reformat.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Tue Sep  6 16:52:14 2016
New Revision: 280757

URL: http://llvm.org/viewvc/llvm-project?rev=280757&view=rev
Log:
Make LLDB compile on Windows after the reformat.

Most of these issues arose as a result of header re-ordering, but
it turned up a real bug, which is that MSVC doesn't support
__attribute__((packed)) or __attribute__((aligned)).  This was
working before because there's a Windows header that #defines
__attribute__(x) to nothing.  We should fix this by removing
that #define entirely, and dealing with the fallout separately
which may turn up even more bugs.

I fixed this by replacing them with the corresponding LLVM
macros which understand how to do these operations on all the
different compilers.

Modified:
lldb/trunk/include/lldb/Host/windows/AutoHandle.h
lldb/trunk/source/Plugins/Process/Utility/RegisterContext_x86.h

Modified: lldb/trunk/include/lldb/Host/windows/AutoHandle.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/windows/AutoHandle.h?rev=280757&r1=280756&r2=280757&view=diff
==
--- lldb/trunk/include/lldb/Host/windows/AutoHandle.h (original)
+++ lldb/trunk/include/lldb/Host/windows/AutoHandle.h Tue Sep  6 16:52:14 2016
@@ -10,6 +10,8 @@
 #ifndef LLDB_lldb_Host_windows_AutoHandle_h_
 #define LLDB_lldb_Host_windows_AutoHandle_h_
 
+#include "lldb/Host/windows/windows.h"
+
 namespace lldb_private {
 
 class AutoHandle {

Modified: lldb/trunk/source/Plugins/Process/Utility/RegisterContext_x86.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Utility/RegisterContext_x86.h?rev=280757&r1=280756&r2=280757&view=diff
==
--- lldb/trunk/source/Plugins/Process/Utility/RegisterContext_x86.h (original)
+++ lldb/trunk/source/Plugins/Process/Utility/RegisterContext_x86.h Tue Sep  6 
16:52:14 2016
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#include "llvm/Support/Compiler.h"
+
 //---
 // i386 ehframe, dwarf regnums
 //---
@@ -285,14 +287,17 @@ struct YMM {
   YMMReg ymm[16]; // assembled from ymmh and xmm registers
 };
 
+LLVM_PACKED_START
 struct XSAVE_HDR {
   uint64_t xstate_bv; // OS enabled xstate mask to determine the extended 
states
   // supported by the processor
   uint64_t reserved1[2];
   uint64_t reserved2[5];
-} __attribute__((packed));
+};
+LLVM_PACKED_END
 
 // x86 extensions to FXSAVE (i.e. for AVX processors)
+LLVM_PACKED_START
 struct XSAVE {
   FXSAVE i387;  // floating point registers typical in i387_fxsave_struct
   XSAVE_HDR header; // The xsave_hdr_struct can be used to determine if the
@@ -300,7 +305,8 @@ struct XSAVE {
   YMMHReg ymmh[16]; // High 16 bytes of each of 16 YMM registers (the low bytes
 // are in FXSAVE.xmm for compatibility with SSE)
 // Slot any extensions to the register file here
-} __attribute__((packed, aligned(64)));
+} LLVM_ALIGNAS(64);
+LLVM_PACKED_END
 
 // Floating-point registers
 struct FPR {


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

Re: [Lldb-commits] [lldb] r280755 - Reorder FreeBSD Host.cpp #includes to fix build

[Zachary Turner via lldb-commits]

Why was this causing a problem?  The only headers that were re-ordered are
system headers.  Does FreeBSD's libraries have requirements about certain
headers being included before other headers?

On Tue, Sep 6, 2016 at 2:33 PM Ed Maste via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: emaste
> Date: Tue Sep  6 16:25:31 2016
> New Revision: 280755
>
> URL: http://llvm.org/viewvc/llvm-project?rev=280755&view=rev
> Log:
> Reorder FreeBSD Host.cpp #includes to fix build
>
> Modified:
> lldb/trunk/source/Host/freebsd/Host.cpp
>
> Modified: lldb/trunk/source/Host/freebsd/Host.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/freebsd/Host.cpp?rev=280755&r1=280754&r2=280755&view=diff
>
> ==
> --- lldb/trunk/source/Host/freebsd/Host.cpp (original)
> +++ lldb/trunk/source/Host/freebsd/Host.cpp Tue Sep  6 16:25:31 2016
> @@ -9,17 +9,19 @@
>
>  
> //===--===//
>
>  // C Includes
> -#include 
> -#include 
> -#include 
> +#include 
> +
> +#include 
>  #include 
> +#include 
>  #include 
> -#include 
>  #include 
>
>  #include 
> -#include 
> -#include 
> +
> +#include 
> +#include 
> +#include 
>
>  // C++ Includes
>  // Other libraries and framework includes
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r280755 - Reorder FreeBSD Host.cpp #includes to fix build

[Dimitry Andric via lldb-commits]

In general,  and  headers should be at the top, followed by 
standard headers such as , then followed by application-specific 
headers.  IIRC this is also the case for Linux.

-Dimitry

> On 07 Sep 2016, at 00:02, Zachary Turner via lldb-commits 
>  wrote:
> 
> Why was this causing a problem?  The only headers that were re-ordered are 
> system headers.  Does FreeBSD's libraries have requirements about certain 
> headers being included before other headers?
> 
> On Tue, Sep 6, 2016 at 2:33 PM Ed Maste via lldb-commits 
> mailto:lldb-commits@lists.llvm.org>> wrote:
> Author: emaste
> Date: Tue Sep  6 16:25:31 2016
> New Revision: 280755
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=280755&view=rev 
> 
> Log:
> Reorder FreeBSD Host.cpp #includes to fix build
> 
> Modified:
> lldb/trunk/source/Host/freebsd/Host.cpp
> 
> Modified: lldb/trunk/source/Host/freebsd/Host.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/freebsd/Host.cpp?rev=280755&r1=280754&r2=280755&view=diff
>  
> 
> ==
> --- lldb/trunk/source/Host/freebsd/Host.cpp (original)
> +++ lldb/trunk/source/Host/freebsd/Host.cpp Tue Sep  6 16:25:31 2016
> @@ -9,17 +9,19 @@
>  
> //===--===//
> 
>  // C Includes
> -#include 
> -#include 
> -#include 
> +#include 
> +
> +#include 
>  #include 
> +#include 
>  #include 
> -#include 
>  #include 
> 
>  #include 
> -#include 
> -#include 
> +
> +#include 
> +#include 
> +#include 
> 
>  // C++ Includes
>  // Other libraries and framework includes
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r280758 - Put the LLVM_ALIGNAS directive in the right place.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Tue Sep  6 17:02:06 2016
New Revision: 280758

URL: http://llvm.org/viewvc/llvm-project?rev=280758&view=rev
Log:
Put the LLVM_ALIGNAS directive in the right place.

Modified:
lldb/trunk/source/Plugins/Process/Utility/RegisterContext_x86.h

Modified: lldb/trunk/source/Plugins/Process/Utility/RegisterContext_x86.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Utility/RegisterContext_x86.h?rev=280758&r1=280757&r2=280758&view=diff
==
--- lldb/trunk/source/Plugins/Process/Utility/RegisterContext_x86.h (original)
+++ lldb/trunk/source/Plugins/Process/Utility/RegisterContext_x86.h Tue Sep  6 
17:02:06 2016
@@ -298,14 +298,14 @@ LLVM_PACKED_END
 
 // x86 extensions to FXSAVE (i.e. for AVX processors)
 LLVM_PACKED_START
-struct XSAVE {
+struct LLVM_ALIGNAS(64) XSAVE {
   FXSAVE i387;  // floating point registers typical in i387_fxsave_struct
   XSAVE_HDR header; // The xsave_hdr_struct can be used to determine if the
 // following extensions are usable
   YMMHReg ymmh[16]; // High 16 bytes of each of 16 YMM registers (the low bytes
 // are in FXSAVE.xmm for compatibility with SSE)
 // Slot any extensions to the register file here
-} LLVM_ALIGNAS(64);
+};
 LLVM_PACKED_END
 
 // Floating-point registers


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

Re: [Lldb-commits] [lldb] r280755 - Reorder FreeBSD Host.cpp #includes to fix build

[Kamil Rytarowski via lldb-commits]

On NetBSD /usr/share/misc/style says:

 


/*
 * Kernel include files come first.
 */
#include           /*  first, */
#include           /*    next, */
#include           /*   and then the rest, */
#include          /*   sorted lexicographically.  */
#include 
#include            /* Non-local includes in brackets.  */

/*
 * If it's a network program, put the network include files next.
 * Group the includes files by subdirectory.
 */
#include 
#include 
#include 
#include 
#include 

/*
 * Then there's a blank line, followed by the /usr include files.
 * The /usr include files should be sorted lexicographically!
 */
#include 
#include 
#include 
#include 
#include 

/*
 * Global pathnames are defined in /usr/include/paths.h.  Pathnames local
 * to the program go in pathnames.h in the local directory.
 */
#include 

/* Then, there's a blank line, and the user include files. */
#include "pathnames.h"          /* Local includes in double quotes. */

 

While the order of standard C headers can be pretty arbitrary, the system ones shall be included in the above order.



It's crucial for  and  to be on a top as other headers may assume that they were

already included.

 


Sent: Wednesday, September 07, 2016 at 12:05 AM
From: "Dimitry Andric via lldb-commits" 
To: "Zachary Turner" 
Cc: lldb-commits@lists.llvm.org
Subject: Re: [Lldb-commits] [lldb] r280755 - Reorder FreeBSD Host.cpp #includes to fix build



In general,  and  headers should be at the top, followed by standard headers such as , then followed by application-specific headers.  IIRC this is also the case for Linux.

 

-Dimitry
 



On 07 Sep 2016, at 00:02, Zachary Turner via lldb-commits  wrote:
 


Why was this causing a problem?  The only headers that were re-ordered are system headers.  Does FreeBSD's libraries have requirements about certain headers being included before other headers?
 


On Tue, Sep 6, 2016 at 2:33 PM Ed Maste via lldb-commits  wrote:

Author: emaste
Date: Tue Sep  6 16:25:31 2016
New Revision: 280755

URL: http://llvm.org/viewvc/llvm-project?rev=280755&view=rev
Log:
Reorder FreeBSD Host.cpp #includes to fix build

Modified:
    lldb/trunk/source/Host/freebsd/Host.cpp

Modified: lldb/trunk/source/Host/freebsd/Host.cpp
URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/freebsd/Host.cpp?rev=280755&r1=280754&r2=280755&view=diff
==
--- lldb/trunk/source/Host/freebsd/Host.cpp (original)
+++ lldb/trunk/source/Host/freebsd/Host.cpp Tue Sep  6 16:25:31 2016
@@ -9,17 +9,19 @@
 //===--===//

 // C Includes
-#include 
-#include 
-#include 
+#include 
+
+#include 
 #include 
+#include 
 #include 
-#include 
 #include 

 #include 
-#include 
-#include 
+
+#include 
+#include 
+#include 

 // C++ Includes
 // Other libraries and framework includes


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

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



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



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

Re: [Lldb-commits] [lldb] r280755 - Reorder FreeBSD Host.cpp #includes to fix build

[Zachary Turner via lldb-commits]

Thanks for clarifying.  That said, I think we should still follow the LLVM
convention of putting system headers last.  (i.e. everything in <> comes
after everything in "", but within <> you can still arrange according to
the system rules).  This encourages "include what you use" as header files
will be required to include any system headers they depend on, rather than
relying on every TU that includes that header to do it.

On Tue, Sep 6, 2016 at 3:17 PM Kamil Rytarowski  wrote:

> On NetBSD /usr/share/misc/style says:
>
> /*
>  * Kernel include files come first.
>  */
> #include   /*  first, */
> #include   /*next, */
> #include   /*   and then the rest, */
> #include  /*   sorted lexicographically.  */
> #include 
> #include/* Non-local includes in brackets.  */
> /*
>  * If it's a network program, put the network include files next.
>  * Group the includes files by subdirectory.
>  */
> #include 
> #include 
> #include 
> #include 
> #include 
> /*
>  * Then there's a blank line, followed by the /usr include files.
>  * The /usr include files should be sorted lexicographically!
>  */
> #include 
> #include 
> #include 
> #include 
> #include 
> /*
>  * Global pathnames are defined in /usr/include/paths.h.  Pathnames local
>  * to the program go in pathnames.h in the local directory.
>  */
> #include 
> /* Then, there's a blank line, and the user include files. */
> #include "pathnames.h"  /* Local includes in double quotes. */
>
> While the order of standard C headers can be pretty arbitrary, the system
> ones shall be included in the above order.
> It's crucial for  and  to be on a top as other
> headers may assume that they were
> already included.
>
> *Sent:* Wednesday, September 07, 2016 at 12:05 AM
> *From:* "Dimitry Andric via lldb-commits" 
> *To:* "Zachary Turner" 
> *Cc:* lldb-commits@lists.llvm.org
> *Subject:* Re: [Lldb-commits] [lldb] r280755 - Reorder FreeBSD Host.cpp
> #includes to fix build
> In general,  and  headers should be at the top, followed
> by standard headers such as , then followed by
> application-specific headers.  IIRC this is also the case for Linux.
>
> -Dimitry
>
>
> On 07 Sep 2016, at 00:02, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
> Why was this causing a problem?  The only headers that were re-ordered are
> system headers.  Does FreeBSD's libraries have requirements about certain
> headers being included before other headers?
>
> On Tue, Sep 6, 2016 at 2:33 PM Ed Maste via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
> Author: emaste
> Date: Tue Sep  6 16:25:31 2016
> New Revision: 280755
>
> URL: http://llvm.org/viewvc/llvm-project?rev=280755&view=rev
> Log:
> Reorder FreeBSD Host.cpp #includes to fix build
>
> Modified:
> lldb/trunk/source/Host/freebsd/Host.cpp
>
> Modified: lldb/trunk/source/Host/freebsd/Host.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/freebsd/Host.cpp?rev=280755&r1=280754&r2=280755&view=diff
>
> ==
> --- lldb/trunk/source/Host/freebsd/Host.cpp (original)
> +++ lldb/trunk/source/Host/freebsd/Host.cpp Tue Sep  6 16:25:31 2016
> @@ -9,17 +9,19 @@
>
>  
> //===--===//
>
>  // C Includes
> -#include 
> -#include 
> -#include 
> +#include 
> +
> +#include 
>  #include 
> +#include 
>  #include 
> -#include 
>  #include 
>
>  #include 
> -#include 
> -#include 
> +
> +#include 
> +#include 
> +#include 
>
>  // C++ Includes
>  // Other libraries and framework includes
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
>
> ___ lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r280759 - Fix tests on Windows.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Tue Sep  6 17:14:22 2016
New Revision: 280759

URL: http://llvm.org/viewvc/llvm-project?rev=280759&view=rev
Log:
Fix tests on Windows.

This wasn't actually a problem with the reformat, but rather a
problem with Visual Studio 2015 Update 3, which uses some c++14
features in its standard libraries.  So we had to change -std=c++11
to -std=c++14.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules

Modified: lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules?rev=280759&r1=280758&r2=280759&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules Tue Sep  6 
17:14:22 2016
@@ -216,7 +216,7 @@ ifeq "$(MAKE_GMODULES)" "YES"
CFLAGS += -fmodules -gmodules
 endif
 
-CXXFLAGS += -std=c++11
+CXXFLAGS += -std=c++14
 # FIXME: C++ modules aren't supported on all platforms.
 CXXFLAGS += $(subst -fmodules,, $(CFLAGS))
 LD = $(CC)
@@ -444,7 +444,7 @@ ifneq "$(filter g++,$(CXX))" ""
ifeq "$(CXXVERSION)" "4.6"
 # GCC 4.6 cannot handle -std=c++11, so replace it with 
-std=c++0x
 # instead. FIXME: remove once GCC version is upgraded.
-   override CXXFLAGS := $(subst -std=c++11,-std=c++0x,$(CXXFLAGS))
+   override CXXFLAGS := $(subst -std=c++14,-std=c++0x,$(CXXFLAGS))
endif
 endif
 endif


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

Re: [Lldb-commits] [PATCH] D24251: LLDB: API for Permission of object file's sections

[Eugene Zelenko via lldb-commits]

Eugene.Zelenko added a subscriber: Eugene.Zelenko.
Eugene.Zelenko added a comment.

Please rebase code on trunk and run Clang-format.


https://reviews.llvm.org/D24251



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

[Lldb-commits] [lldb] r280763 - Revert "Fix tests on Windows."

[Zachary Turner via lldb-commits]

Author: zturner
Date: Tue Sep  6 17:40:11 2016
New Revision: 280763

URL: http://llvm.org/viewvc/llvm-project?rev=280763&view=rev
Log:
Revert "Fix tests on Windows."

This reverts commit 9b757b6e3946311802972409f38c6cefbea917b3.

This seems to cause strange breakages about on Ubuntu.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules

Modified: lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules?rev=280763&r1=280762&r2=280763&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules Tue Sep  6 
17:40:11 2016
@@ -216,7 +216,7 @@ ifeq "$(MAKE_GMODULES)" "YES"
CFLAGS += -fmodules -gmodules
 endif
 
-CXXFLAGS += -std=c++14
+CXXFLAGS += -std=c++11
 # FIXME: C++ modules aren't supported on all platforms.
 CXXFLAGS += $(subst -fmodules,, $(CFLAGS))
 LD = $(CC)
@@ -444,7 +444,7 @@ ifneq "$(filter g++,$(CXX))" ""
ifeq "$(CXXVERSION)" "4.6"
 # GCC 4.6 cannot handle -std=c++11, so replace it with 
-std=c++0x
 # instead. FIXME: remove once GCC version is upgraded.
-   override CXXFLAGS := $(subst -std=c++14,-std=c++0x,$(CXXFLAGS))
+   override CXXFLAGS := $(subst -std=c++11,-std=c++0x,$(CXXFLAGS))
endif
 endif
 endif


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

Re: [Lldb-commits] [PATCH] D24283: [lldb] Set the correct triple when creating an ArchSpec for windows

[Zachary Turner via lldb-commits]

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

Does this affect the running of the test suite in any way?  Is anything fixed 
or regressed as a result of this?


Repository:
  rL LLVM

https://reviews.llvm.org/D24283



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

Re: [Lldb-commits] [PATCH] D24283: [lldb] Set the correct triple when creating an ArchSpec for windows

[Zachary Turner via lldb-commits]

zturner added a comment.

BTW, you will need to rebase this on top of trunk, and make sure you run 
clang-format before submitting.


Repository:
  rL LLVM

https://reviews.llvm.org/D24283



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

Re: [Lldb-commits] [PATCH] D24284: [lldb] Read modules from memory when a local copy is not available

[Zachary Turner via lldb-commits]

zturner added a comment.

Can you rebase on top of tunk and re-upload?  Also please use -U99 when 
generating the diff (assuming you are using git) so we can see context.


Repository:
  rL LLVM

https://reviews.llvm.org/D24284



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

Re: [Lldb-commits] [PATCH] D24284: [lldb] Read modules from memory when a local copy is not available

[Zachary Turner via lldb-commits]

zturner added a comment.

Right, I'm just wondering if when you run `ninja check-lldb` before and after 
this patch, do the results differ at all?


Repository:
  rL LLVM

https://reviews.llvm.org/D24284



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

Re: [Lldb-commits] [PATCH] D24283: [lldb] Set the correct triple when creating an ArchSpec for windows

[Zachary Turner via lldb-commits]

zturner added a comment.

In https://reviews.llvm.org/D24283#535405, @wallace wrote:

> This fixes some issues with arm architectures (where this was unsetting the 
> thumbv7 and was fallbacking to thumb).
>  This is also needed for https://reviews.llvm.org/D24284, where the objet 
> file requires a correct architecture inferred from the machine arch


Right, I'm just wondering if when you run `ninja check-lldb` before and after 
this patch, do the results differ at all?


Repository:
  rL LLVM

https://reviews.llvm.org/D24283



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

Re: [Lldb-commits] [PATCH] D24283: [lldb] Set the correct triple when creating an ArchSpec for windows

[walter erquinigo via lldb-commits]

wallace added a comment.

oh, thank you, first time i'm sending lldb diffs


Repository:
  rL LLVM

https://reviews.llvm.org/D24283



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

Re: [Lldb-commits] [PATCH] D24283: [lldb] Set the correct triple when creating an ArchSpec for windows

[walter erquinigo via lldb-commits]

wallace added a comment.

This fixes some issues with arm architectures (where this was unsetting the 
thumbv7 and was fallbacking to thumb).
This is also needed for https://reviews.llvm.org/D24284, where the objet file 
requires a correct architecture inferred from the machine arch


Repository:
  rL LLVM

https://reviews.llvm.org/D24283



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

[Lldb-commits] [PATCH] D24284: [lldb] Read modules from memory when a local copy is not available

[walter erquinigo via lldb-commits]

wallace created this revision.
wallace added reviewers: zturner, sas.
wallace added a subscriber: LLDB.
wallace set the repository for this revision to rL LLVM.
wallace added a project: LLDB.

When the local lldb doesn't have access to a copy of the modules in the target, 
e.g. winphone, with this change now we read these modules from memory.

There are mainly 3 changes:
1. set the correct OS when definingn the arch of pecoff files
2. create pecoff object files from memory
3. read from memory when the local file is not available


Repository:
  rL LLVM

https://reviews.llvm.org/D24284

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

Index: lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h
===
--- lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h
+++ lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h
@@ -166,6 +166,13 @@
 bool
 IsThumb();
 
+ObjectFilePECOFF(const lldb::ModuleSP &module_sp,
+ lldb::DataBufferSP& header_data_sp,
+ const lldb::ProcessSP &process_sp,
+ lldb::addr_t header_addr);
+
+lldb_private::DataExtractor ReadImageData(uint32_t offset, size_t size);
+
 protected:
 	bool NeedsEndianSwap() const;
 
Index: lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
===
--- lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
+++ lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
@@ -14,6 +14,7 @@
 
 #include "lldb/Core/ArchSpec.h"
 #include "lldb/Core/DataBuffer.h"
+#include "lldb/Core/DataBufferHeap.h"
 #include "lldb/Host/FileSpec.h"
 #include "lldb/Core/FileSpecList.h"
 #include "lldb/Core/Module.h"
@@ -101,6 +102,12 @@
 const lldb::ProcessSP &process_sp, 
 lldb::addr_t header_addr)
 {
+if (data_sp && ObjectFilePECOFF::MagicBytesMatch(data_sp)) {
+std::auto_ptr objfile_ap(new ObjectFilePECOFF(module_sp, data_sp, process_sp, header_addr));
+if (objfile_ap.get() && objfile_ap->ParseHeader()) {
+return objfile_ap.release();
+}
+}
 return NULL;
 }
 
@@ -205,6 +212,21 @@
 ::memset (&m_coff_header_opt, 0, sizeof(m_coff_header_opt));
 }
 
+ObjectFilePECOFF::ObjectFilePECOFF (const lldb::ModuleSP &module_sp,
+DataBufferSP& header_data_sp,
+const lldb::ProcessSP &process_sp,
+addr_t header_addr) :
+ObjectFile(module_sp, process_sp, header_addr, header_data_sp),
+m_dos_header (),
+m_coff_header (),
+m_coff_header_opt (),
+m_sect_headers (),
+m_entry_point_address ()
+{
+::memset (&m_dos_header, 0, sizeof(m_dos_header));
+::memset (&m_coff_header, 0, sizeof(m_coff_header));
+::memset (&m_coff_header_opt, 0, sizeof(m_coff_header_opt));
+}
 
 ObjectFilePECOFF::~ObjectFilePECOFF()
 {
@@ -465,6 +487,33 @@
 return success;
 }
 
+DataExtractor ObjectFilePECOFF::ReadImageData(uint32_t offset, size_t size) {
+DataExtractor data;
+if (m_file)
+{
+DataBufferSP buffer_sp (m_file.ReadFileContents (offset, size));
+data = DataExtractor(buffer_sp, GetByteOrder(), GetAddressByteSize ());
+}
+else
+{
+ProcessSP process_sp (m_process_wp.lock());
+if (process_sp)
+{
+std::unique_ptr data_ap (new DataBufferHeap (size, 0));
+Error readmem_error;
+size_t bytes_read = process_sp->ReadMemory (m_image_base + offset,
+data_ap->GetBytes(),
+data_ap->GetByteSize(),
+readmem_error);
+if (bytes_read == size)
+{
+DataBufferSP buffer_sp (data_ap.release());
+data.SetData (buffer_sp, 0, buffer_sp->GetByteSize());
+}
+}
+}
+return data;
+}
 
 //--
 // ParseSectionHeaders
@@ -477,10 +526,8 @@
 
 if (nsects > 0)
 {
-const uint32_t addr_byte_size = GetAddressByteSize ();
 const size_t section_header_byte_size = nsects * sizeof(section_header_t);
-DataBufferSP section_header_data_sp(m_file.ReadFileContents (section_header_data_offset, section_header_byte_size));
-DataExtractor section_header_data (section_header_data_sp, GetByteOrder(), addr_byte_size);
+DataExtractor section_header_data = ReadImageData (section_header_data_offset, section_header_byte_size);
 
 lldb::offset_t offset = 0;
 if (section_header_data.Valid