Re: [Lldb-commits] [lldb] r303907 - Fix bug #28898

[Ulrich Weigand via lldb-commits]

chris...@zoulas.com (Christos Zoulas) wrote on 30.05.2017 17:46:58:

> I am sorry to say that this is my fault and this sucks. I accepted
> some patches that broke binary compatibility in a way that it is not
> user visible. Basically you seem to have version of libedit that is
> between the narrow one that works, and the wide one that has the
> binary compatibility of the wide code removed.
>
> | I managed to debug a bit myself, and I think the problem is this:
>
> Yes, this is correct. Basically your version of libedit handles
> properly the narrow char read function and breaks if it is defined
> as a wide char. if your histedit header does not have EL_ALIAS_TEXT
> defined, you can check for that define too and not use the wide read
> if that is not defined. Unfortunately there was no other change in
> the version that would help differentiating the two libedit versions.
>
> To fix this properly we would require an updated version of libedit.

Hmm, from looking at the version of libedit I'm using it would
appear that it should correctly handle either:
- a narrow char read function installed via el_set; or
- a wide char read function installed via el_wset
which seems reasonable to me at first glance.

However, LLDB currently uses a wide char read function but installs
it with el_set, which is what breaks.  This would seem to be rather
a LLDB problem, or am I missing something?

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

Re: [Lldb-commits] [lldb] r303907 - Fix bug #28898

[Ulrich Weigand via lldb-commits]

Kamil Rytarowski  wrote on 29.05.2017 18:10:36:

> Do you offer shell account? I don't have Linux and/or s390x to debug it.

Sorry, this is on an internal IBM machine ... I don't have a publically
accessible machine to reproduce this on at the moment.

I managed to debug a bit myself, and I think the problem is this:

After your change, this routine:
int Editline::GetCharacter(EditLineGetCharType *c) {
now has a "wchar_t *" argument, and stores the output character
as a 4-byte wide character on Linux.

However, the caller of this routine does this (this is the Fedora 24
version of libedit - libedit-3.1-14.20150325cvs.fc24.src.rpm):

num_read = (*el->el_read.read_char)(el, cp);
if (num_read < 0)
el->el_errno = errno;
#ifdef WIDECHAR
if (el->el_flags & NARROW_READ)
*cp = *(char *)(void *)cp;
#endif

In my case, the (el->el_flags & NARROW_READ) is true, so it
accesses the wchar_t as a char and extends that to a wchar_t.

On a little-endian machine, this would be a no-op, but on a
big-endian machine, this basically always set the character
to 0.

Now, the question is why is the NARROW_READ flag set.  It
appears this is the case because the EL_GETCFN call that
installs the callback used el_set, not el_wset (that is
what triggers setting vs. clearing NARROW_READ).

The LLDB code does *appear* to use el_wset:
  el_wset(m_editline, EL_GETCFN, (EditlineGetCharCallbackType)([](
 EditLine *editline,
EditLineGetCharType *c) {
return Editline::InstanceFor(editline)->GetCharacter(c);
  }));

but that's not actually true, because of:

#if LLDB_EDITLINE_USE_WCHAR
[...]
#else
[...]
#define el_wset el_set
[...]
#endif // #if LLDB_EDITLINE_USE_WCHAR

at the top of the file.  Note that on Linux, it appears
LLDB_EDITLINE_USE_WCHAR is unconditionally set to 0:

#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) ||
\
defined(__OpenBSD__)
#define LLDB_EDITLINE_USE_WCHAR 1
#include 
#else
#define LLDB_EDITLINE_USE_WCHAR 0
#endif

So in general, it looks like the bug is that LLDB on Linux
always installs the EL_GETFCN callback using el_set, which
causes libedit to assume it actually takes a char *
argument, but LLDB now defines the routine as taking a
wchar_t * argument, which causes the character to be always
read as 0 on all big-endian Linux systems.


Is this enough information for you to fix the problem?
If you'd like me to do more debugging, please let me know.

Bye,
Ulrich

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

Re: [Lldb-commits] [lldb] r303907 - Fix bug #28898

[Ulrich Weigand via lldb-commits]

Hello,

It appears this commit broke the
EditlineTestFixture.EditlineReceivesSingleLineText
unit test on s390x-linux.  The test now simply hangs (hanging the whole
test suite
execution) ...

Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU/Linux compilers and toolchain
  IBM Deutschland Research & Development GmbH
  Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D20368: Remove Platform usages from NativeProcessLinux

[Ulrich Weigand via lldb-commits]

uweigand added a comment.

This patch builds and works fine on s390x-linux.


http://reviews.llvm.org/D20368



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

Re: [Lldb-commits] [PATCH] D18976: Handle lookup of names identifying both a variable and a type

[Ulrich Weigand via lldb-commits]

uweigand added a reviewer: jingham.
uweigand updated this revision to Diff 57617.
uweigand added a comment.

Ping?  This fixes the last remaining test suite failure on s390x.  I'd like to 
get a clean test suite ...

Patch updated to current sources.

Added jingham since you touched that code recently.


http://reviews.llvm.org/D18976

Files:
  packages/Python/lldbsuite/test/lang/cpp/scope/TestCppScope.py
  packages/Python/lldbsuite/test/lang/cpp/scope/main.cpp
  source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp

Index: source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
@@ -866,8 +866,11 @@
  current_id);
 }
 
-if (!context.m_found.variable && !context.m_found.local_vars_nsp)
-ClangASTSource::FindExternalVisibleDecls(context);
+// Always call into ClangASTSource::FindExternalVisibleDecls, even if we 
already found
+// some decls above.  It might be that Clang is looking for a type, but we 
have found
+// a variable of the same name instead.  Let ClangASTSource add the type 
to the result
+// list as well; Clang will filter out the decl it is actually interested 
in.
+ClangASTSource::FindExternalVisibleDecls(context);
 }
 
 void
Index: packages/Python/lldbsuite/test/lang/cpp/scope/main.cpp
===
--- packages/Python/lldbsuite/test/lang/cpp/scope/main.cpp
+++ packages/Python/lldbsuite/test/lang/cpp/scope/main.cpp
@@ -19,6 +19,10 @@
 int C::a = ;
 int a = ;
 
+// Verify that LLDB is able to parse "C::a" even when "C" exists both as a
+// type name and a variable name at the same time.
+int C = ;
+
 int main() // break here
 {
 return 0;
Index: packages/Python/lldbsuite/test/lang/cpp/scope/TestCppScope.py
===
--- packages/Python/lldbsuite/test/lang/cpp/scope/TestCppScope.py
+++ packages/Python/lldbsuite/test/lang/cpp/scope/TestCppScope.py
@@ -54,10 +54,12 @@
 'B::a': ,
 'C::a': ,
 '::a': ,
-'a': 
+'a': ,
+'::C': ,
+'C': 
 }
 
-self.assertTrue(global_variables.GetSize() == 4, "target variable 
returns all variables")
+self.assertTrue(global_variables.GetSize() == 5, "target variable 
returns all variables")
 for variable in global_variables:
 name = variable.GetName()
 self.assertTrue(name in global_variables_assert, "target variable 
returns wrong variable " + name)


Index: source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
@@ -866,8 +866,11 @@
  current_id);
 }
 
-if (!context.m_found.variable && !context.m_found.local_vars_nsp)
-ClangASTSource::FindExternalVisibleDecls(context);
+// Always call into ClangASTSource::FindExternalVisibleDecls, even if we already found
+// some decls above.  It might be that Clang is looking for a type, but we have found
+// a variable of the same name instead.  Let ClangASTSource add the type to the result
+// list as well; Clang will filter out the decl it is actually interested in.
+ClangASTSource::FindExternalVisibleDecls(context);
 }
 
 void
Index: packages/Python/lldbsuite/test/lang/cpp/scope/main.cpp
===
--- packages/Python/lldbsuite/test/lang/cpp/scope/main.cpp
+++ packages/Python/lldbsuite/test/lang/cpp/scope/main.cpp
@@ -19,6 +19,10 @@
 int C::a = ;
 int a = ;
 
+// Verify that LLDB is able to parse "C::a" even when "C" exists both as a
+// type name and a variable name at the same time.
+int C = ;
+
 int main() // break here
 {
 return 0;
Index: packages/Python/lldbsuite/test/lang/cpp/scope/TestCppScope.py
===
--- packages/Python/lldbsuite/test/lang/cpp/scope/TestCppScope.py
+++ packages/Python/lldbsuite/test/lang/cpp/scope/TestCppScope.py
@@ -54,10 +54,12 @@
 'B::a': ,
 'C::a': ,
 '::a': ,
-'a': 
+'a': ,
+'::C': ,
+'C': 
 }
 
-self.assertTrue(global_variables.GetSize() == 4, "target variable returns all variables")
+self.assertTrue(global_variables.GetSize() == 5, "target variable returns all variables")
 for variable in global_variables:
 name = variable.GetName()
 self.assert

Re: [Lldb-commits] [PATCH] D18975: Fix unwind failures when PC points beyond the end of a function

[Ulrich Weigand via lldb-commits]

uweigand added a comment.

Given Tamas' update, I've now checked in the original version, including 
comment.  If you do want me to take out the comment after all, please let me 
know and I'll do so.


Repository:
  rL LLVM

http://reviews.llvm.org/D18975



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

[Lldb-commits] [lldb] r267363 - Fix unwind failures when PC points beyond the end of a function

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Sun Apr 24 15:49:56 2016
New Revision: 267363

URL: http://llvm.org/viewvc/llvm-project?rev=267363&view=rev
Log:
Fix unwind failures when PC points beyond the end of a function

RegisterContextLLDB::InitializeNonZerothFrame already has code to attempt
to detect and handle the case where the PC points beyond the end of a
function, but there are certain cases where this doesn't work correctly.

In fact, there are *two* different places where this detection is attempted,
and the failure is in fact a result of an unfortunate interaction between
those two separate attempts.

First, the ResolveSymbolContextForAddress routine is called with the
resolve_tail_call_address flag set to true.  This causes the routine
to internally accept a PC pointing beyond the end of a function, and
still resolving the PC to that function symbol.

Second, the InitializeNonZerothFrame routine itself maintains a
"decr_pc_and_recompute_addr_range" flag and, if that turns out to
be true, itself decrements the PC by one and searches again for
a symbol at that new PC value.

Both approaches correctly identify the symbol associated with the PC.
However, the problem is now that later on, we also need to find the
DWARF CFI record associated with the PC.  This is done in the
RegisterContextLLDB::GetFullUnwindPlanForFrame routine, and uses
the "m_current_offset_backed_up_one" member variable.

However, that variable only actually contains the PC "backed up by
one" if the *second* approach above was taken.  If the function was
already identified via the first approach above, that member variable
is *not* backed up by one but simply points to the original PC.
This in turn causes GetEHFrameUnwindPlan to not correctly identify
the DWARF CFI record associated with the PC.

Now, in many cases, if the first method had to back up the PC by one,
we *still* use the second method too, because of this piece of code:

// Or if we're in the middle of the stack (and not "above" an asynchronous 
event like sigtramp),
// and our "current" pc is the start of a function...
if (m_sym_ctx_valid
&& GetNextFrame()->m_frame_type != eTrapHandlerFrame
&& GetNextFrame()->m_frame_type != eDebuggerFrame
&& addr_range.GetBaseAddress().IsValid()
&& addr_range.GetBaseAddress().GetSection() == m_current_pc.GetSection()
&& addr_range.GetBaseAddress().GetOffset() == m_current_pc.GetOffset())
{
decr_pc_and_recompute_addr_range = true;
}

In many cases, when the PC is one beyond the end of the current function,
it will indeed then be exactly at the start of the next function.  But this
is not always the case, e.g. if there happens to be alignment padding
between the end of one function and the start of the next.

In those cases, we may sucessfully look up the function symbol via
ResolveSymbolContextForAddress, but *not* set decr_pc_and_recompute_addr_range,
and therefore fail to find the correct DWARF CFI record.

A very simple fix for this problem is to just never use the first method.
Call ResolveSymbolContextForAddress with resolve_tail_call_address set
to false, which will cause it to fail if the PC is beyond the end of
the current function; or else, identify the next function if the PC
is also at the start of the next function.  In either case, we will
then set the decr_pc_and_recompute_addr_range variable and back up the
PC anyway, but this time also find the correct DWARF CFI.

A related problem is that the ResolveSymbolContextForAddress sometimes
returns a "symbol" with empty name.  This turns out to be an ELF section
symbol.  Now, usually those get type eSymbolTypeInvalid.  However, there
is code in ObjectFileELF::ParseSymbols that tries to change the type of
invalid symbols to eSymbolTypeCode or eSymbolTypeData if the symbol
lies within the code or data section.

Unfortunately, this check also hits the symbol for the code section
itself, which is then marked as eSymbolTypeCode.  While the size of
the section symbol is 0 according to the ELF file, LLDB considers
this size invalid and attempts to figure out the "correct" size.
Depending on how this goes, we may end up with a symbol that overlays
part of the code section, even outside areas covered by real function
symbols.

Therefore, if we call ResolveSymbolContextForAddress with PC pointing
beyond the end of a function, we may get this bogus section symbol.
This again means InitializeNonZerothFrame thinks we have a valid PC,
but then we don't find any unwind info for it.

The fix for this problem is me to simply always leave ELF section
symbols as type eSymbolTypeInvalid.

Differential Revision: http://reviews.llvm.org/D18975


Modified:
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp

Modified: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileEL

Re: [Lldb-commits] [PATCH] D18975: Fix unwind failures when PC points beyond the end of a function

[Ulrich Weigand via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL267363: Fix unwind failures when PC points beyond the end of 
a function (authored by uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18975?vs=53951&id=54813#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18975

Files:
  lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp

Index: lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
===
--- lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
+++ lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
@@ -470,11 +470,13 @@
 return;
 }
 
-bool resolve_tail_call_address = true; // m_current_pc can be one past the 
address range of the function...
-   // This will handle the case where 
the saved pc does not point to 
-   // a function/symbol because it is 
beyond the bounds of the correct
-   // function and there's no symbol 
there.  ResolveSymbolContextForAddress
-   // will fail to find a symbol, back 
up the pc by 1 and re-search.
+bool resolve_tail_call_address = false; // m_current_pc can be one past 
the address range of the function...
+// If the saved pc does not point 
to a function/symbol because it is
+// beyond the bounds of the 
correct function and there's no symbol there,
+// we do *not* want 
ResolveSymbolContextForAddress to back up the pc by 1,
+// because then we might not find 
the correct unwind information later.
+// Instead, let 
ResolveSymbolContextForAddress fail, and handle the case
+// via 
decr_pc_and_recompute_addr_range below.
 const uint32_t resolve_scope = eSymbolContextFunction | 
eSymbolContextSymbol;
 uint32_t resolved_scope = pc_module_sp->ResolveSymbolContextForAddress 
(m_current_pc,
 
resolve_scope,
Index: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -2248,7 +2248,7 @@
 }
 }
 
-if (symbol_type == eSymbolTypeInvalid)
+if (symbol_type == eSymbolTypeInvalid && symbol.getType() != 
STT_SECTION)
 {
 if (symbol_section_sp)
 {


Index: lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
===
--- lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
+++ lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
@@ -470,11 +470,13 @@
 return;
 }
 
-bool resolve_tail_call_address = true; // m_current_pc can be one past the address range of the function...
-   // This will handle the case where the saved pc does not point to 
-   // a function/symbol because it is beyond the bounds of the correct
-   // function and there's no symbol there.  ResolveSymbolContextForAddress
-   // will fail to find a symbol, back up the pc by 1 and re-search.
+bool resolve_tail_call_address = false; // m_current_pc can be one past the address range of the function...
+// If the saved pc does not point to a function/symbol because it is
+// beyond the bounds of the correct function and there's no symbol there,
+// we do *not* want ResolveSymbolContextForAddress to back up the pc by 1,
+// because then we might not find the correct unwind information later.
+// Instead, let ResolveSymbolContextForAddress fail, and handle the case
+// via decr_pc_and_recompute_addr_range below.
 const uint32_t resolve_scope = eSymbolContextFunction | eSymbolContextSymbol;
 uint32_t resolved_scope = pc_module_sp->ResolveSymbolContextForAddress (m_current_pc,
 resolve_scope,
Index: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp

Re: [Lldb-commits] [PATCH] D18975: Fix unwind failures when PC points beyond the end of a function

[Ulrich Weigand via lldb-commits]

uweigand added reviewers: clayborg, tberghammer.
uweigand updated this revision to Diff 53951.
uweigand added a comment.

Add fix for a related problem that still caused unwind failures on SystemZ.

The ResolveSymbolContextForAddress sometimes returns a "symbol" with empty
name.  This turns out to be an ELF section symbol.  Now, usually those get type
eSymbolTypeInvalid.  However, there is code in ObjectFileELF::ParseSymbols
that tries to change the type of invalid symbols to eSymbolTypeCode or
eSymbolTypeData if the symbol lies within the code or data section.

Unfortunately, this check also hits the symbol for the code section
itself, which is then marked as eSymbolTypeCode.  While the size of
the section symbol is 0 according to the ELF file, LLDB considers
this size invalid and attempts to figure out the "correct" size.
Depending on how this goes, we may end up with a symbol that overlays
part of the code section, even outside areas covered by real function
symbols.

Therefore, if we call ResolveSymbolContextForAddress with PC pointing
beyond the end of a function, we may get this bogus section symbol.
This again means InitializeNonZerothFrame thinks we have a valid PC,
but then we don't find any unwind info for it.

The fix for this problem seems to me to simply always leave ELF section
symbols as type eSymbolTypeInvalid.


http://reviews.llvm.org/D18975

Files:
  source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  source/Plugins/Process/Utility/RegisterContextLLDB.cpp

Index: source/Plugins/Process/Utility/RegisterContextLLDB.cpp
===
--- source/Plugins/Process/Utility/RegisterContextLLDB.cpp
+++ source/Plugins/Process/Utility/RegisterContextLLDB.cpp
@@ -470,11 +470,13 @@
 return;
 }
 
-bool resolve_tail_call_address = true; // m_current_pc can be one past the 
address range of the function...
-   // This will handle the case where 
the saved pc does not point to 
-   // a function/symbol because it is 
beyond the bounds of the correct
-   // function and there's no symbol 
there.  ResolveSymbolContextForAddress
-   // will fail to find a symbol, back 
up the pc by 1 and re-search.
+bool resolve_tail_call_address = false; // m_current_pc can be one past 
the address range of the function...
+// If the saved pc does not point 
to a function/symbol because it is
+// beyond the bounds of the 
correct function and there's no symbol there,
+// we do *not* want 
ResolveSymbolContextForAddress to back up the pc by 1,
+// because then we might not find 
the correct unwind information later.
+// Instead, let 
ResolveSymbolContextForAddress fail, and handle the case
+// via 
decr_pc_and_recompute_addr_range below.
 const uint32_t resolve_scope = eSymbolContextFunction | 
eSymbolContextSymbol;
 uint32_t resolved_scope = pc_module_sp->ResolveSymbolContextForAddress 
(m_current_pc,
 
resolve_scope,
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -2148,7 +2148,7 @@
 }
 }
 
-if (symbol_type == eSymbolTypeInvalid)
+if (symbol_type == eSymbolTypeInvalid && symbol.getType() != 
STT_SECTION)
 {
 if (symbol_section_sp)
 {


Index: source/Plugins/Process/Utility/RegisterContextLLDB.cpp
===
--- source/Plugins/Process/Utility/RegisterContextLLDB.cpp
+++ source/Plugins/Process/Utility/RegisterContextLLDB.cpp
@@ -470,11 +470,13 @@
 return;
 }
 
-bool resolve_tail_call_address = true; // m_current_pc can be one past the address range of the function...
-   // This will handle the case where the saved pc does not point to 
-   // a function/symbol because it is beyond the bounds of the correct
-   // function and there's no symbol there.  ResolveSymbolContextForAddress
-   // will fail to find a symbol, back up the pc by 1 and re-search.
+bool resolve_tail_call_address = false; // m_current_pc can be one past the address range of the function...
+// If the saved pc does not point to a function/symbol because it is
+  

[Lldb-commits] [lldb] r266422 - Fix usage of APInt.getRawData for big-endian systems

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Fri Apr 15 04:55:52 2016
New Revision: 266422

URL: http://llvm.org/viewvc/llvm-project?rev=266422&view=rev
Log:
Fix usage of APInt.getRawData for big-endian systems

Recommit modified version of r266311 including build bot regression fix.

This differs from the original r266311 by:

- Fixing Scalar::Promote to correctly zero- or sign-extend value depending
  on signedness of the *source* type, not the target type.

- Omitting a few stand-alone fixes that were already committed separately.


Modified:
lldb/trunk/include/lldb/Core/Scalar.h
lldb/trunk/include/lldb/Symbol/Type.h
lldb/trunk/source/Core/Scalar.cpp
lldb/trunk/source/Expression/IRInterpreter.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
lldb/trunk/source/Symbol/ClangASTContext.cpp
lldb/trunk/unittests/Core/ScalarTest.cpp

Modified: lldb/trunk/include/lldb/Core/Scalar.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Scalar.h?rev=266422&r1=266421&r2=266422&view=diff
==
--- lldb/trunk/include/lldb/Core/Scalar.h (original)
+++ lldb/trunk/include/lldb/Core/Scalar.h Fri Apr 15 04:55:52 2016
@@ -162,6 +162,9 @@ public:
 bool
 MakeSigned ();
 
+bool
+MakeUnsigned ();
+
 static const char *
 GetValueTypeAsCString (Scalar::Type value_type);
 
@@ -239,18 +242,6 @@ public:
 int
 SInt(int fail_value = 0) const;
 
-// Return the raw unsigned integer without any casting or conversion
-unsigned int
-RawUInt () const;
-
-// Return the raw unsigned long without any casting or conversion
-unsigned long
-RawULong () const;
-
-// Return the raw unsigned long long without any casting or conversion
-unsigned long long
-RawULongLong () const;
-
 unsigned char
 UChar(unsigned char fail_value = 0) const;
 
@@ -299,9 +290,6 @@ public:
 long double
 LongDouble(long double fail_value = 0.0) const;
 
-uint64_t
-GetRawBits64 (uint64_t fail_value) const;
-
 Error
 SetValueFromCString (const char *s, lldb::Encoding encoding, size_t 
byte_size);
 

Modified: lldb/trunk/include/lldb/Symbol/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/Type.h?rev=266422&r1=266421&r2=266422&view=diff
==
--- lldb/trunk/include/lldb/Symbol/Type.h (original)
+++ lldb/trunk/include/lldb/Symbol/Type.h Fri Apr 15 04:55:52 2016
@@ -958,13 +958,13 @@ public:
 uint64_t
 GetValueAsUnsigned () const
 {
-return *m_value.getRawData();
+return m_value.getZExtValue();
 }
 
 int64_t
 GetValueAsSigned () const
 {
-return (int64_t) *m_value.getRawData();
+return m_value.getSExtValue();
 }
 
 protected:

Modified: lldb/trunk/source/Core/Scalar.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Scalar.cpp?rev=266422&r1=266421&r2=266422&view=diff
==
--- lldb/trunk/source/Core/Scalar.cpp (original)
+++ lldb/trunk/source/Core/Scalar.cpp Fri Apr 15 04:55:52 2016
@@ -16,6 +16,8 @@
 #include 
 
 // Other libraries and framework includes
+#include "llvm/ADT/SmallString.h"
+
 // Project includes
 #include "lldb/Interpreter/Args.h"
 #include "lldb/Core/Error.h"
@@ -134,10 +136,10 @@ bool
 Scalar::GetData (DataExtractor &data, size_t limit_byte_size) const
 {
 size_t byte_size = GetByteSize();
-static float f_val;
-static double d_val;
 if (byte_size > 0)
 {
+const uint8_t *bytes = reinterpret_cast(GetBytes());
+
 if (limit_byte_size < byte_size)
 {
 if (endian::InlHostByteOrder() == eByteOrderLittle)
@@ -145,105 +147,19 @@ Scalar::GetData (DataExtractor &data, si
 // On little endian systems if we want fewer bytes from the
 // current type we just specify fewer bytes since the LSByte
 // is first...
-switch(m_type)
-{
-case e_void:
-break;
-case e_sint:
-case e_uint:
-case e_slong:
-case e_ulong:
-case e_slonglong:
-case e_ulonglong:
-case e_sint128:
-case e_uint128:
-case e_sint256:
-case e_uint256:
-data.SetData((const uint8_t *)m_integer.getRawData(), 
limit_byte_size, endian::InlHostByteOrder());
-return true;
-case e_float:
-f_val = m_float.convertToFloat();
-data.SetData((uint8_t *)&f_val, limit_byte_size, 
endian::InlHostByteOrder());
-return true;
-case e_double:
-d_val = m_float.convertToDouble();
-  

Re: [Lldb-commits] [PATCH] D18978: Support Linux on SystemZ as platform

[Ulrich Weigand via lldb-commits]

Pavel Labath  wrote on 15.04.2016 11:19:35:

> Thanks a lot for cleaning that up. I hope you'll be able to find the
> cause of the 32-bit problems quickly. If you need help reproducing the
> errors, I can send you some of the detailed logs from our buildbots.

I did manage to find the cause of the 32-bit problems now.  The
modified Scalar::Promote routine made incorrect decisions on when
to zero-extend and when to sign-extend the incoming value.  This
needs to be done based on the signedness of the *source* type of
the Promote, not the target type, which my patch got wrong.

This caused LLDB to incorrectly sign-extend 32-bit target pointer
values to 64-bit host values, which resulted in ptrace errors when
attempting to access target memory at those locations:

AssertionError: False is not True : 'frame variable one' returns expected
result, got '(i_am_cool) one = {
  integer = 

  floating = 

  character = 

I've fixed this now, and those tests no longer fail on my system.
I'm planning on recommitted the fixed patch shortly.

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

[Lldb-commits] [lldb] r266420 - Make Scalar::SChar return an explicit signed type

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Fri Apr 15 04:15:47 2016
New Revision: 266420

URL: http://llvm.org/viewvc/llvm-project?rev=266420&view=rev
Log:
Make Scalar::SChar return an explicit signed type

This is needed for platforms where the default "char" type is unsigned.

Originally committed as part of (now reverted) r266311.


Modified:
lldb/trunk/include/lldb/Core/Scalar.h
lldb/trunk/source/Core/Scalar.cpp

Modified: lldb/trunk/include/lldb/Core/Scalar.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Scalar.h?rev=266420&r1=266419&r2=266420&view=diff
==
--- lldb/trunk/include/lldb/Core/Scalar.h (original)
+++ lldb/trunk/include/lldb/Core/Scalar.h Fri Apr 15 04:15:47 2016
@@ -254,7 +254,7 @@ public:
 unsigned char
 UChar(unsigned char fail_value = 0) const;
 
-char
+signed char
 SChar(char fail_value = 0) const;
 
 unsigned short

Modified: lldb/trunk/source/Core/Scalar.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Scalar.cpp?rev=266420&r1=266419&r2=266420&view=diff
==
--- lldb/trunk/source/Core/Scalar.cpp (original)
+++ lldb/trunk/source/Core/Scalar.cpp Fri Apr 15 04:15:47 2016
@@ -1380,7 +1380,7 @@ Scalar::MakeSigned ()
 return success;
 }
 
-char
+signed char
 Scalar::SChar(char fail_value) const
 {
 switch (m_type)


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

[Lldb-commits] [lldb] r266418 - Fix Scalar::SetValueFromData for 128- and 256-bit types

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Fri Apr 15 04:14:59 2016
New Revision: 266418

URL: http://llvm.org/viewvc/llvm-project?rev=266418&view=rev
Log:
Fix Scalar::SetValueFromData for 128- and 256-bit types

Obvious fix for incorrect use of GetU64 offset pointer.

Originally committed as part of (now reverted) r266311.



Modified:
lldb/trunk/source/Core/Scalar.cpp

Modified: lldb/trunk/source/Core/Scalar.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Scalar.cpp?rev=266418&r1=266417&r2=266418&view=diff
==
--- lldb/trunk/source/Core/Scalar.cpp (original)
+++ lldb/trunk/source/Core/Scalar.cpp Fri Apr 15 04:14:59 2016
@@ -2652,12 +2652,12 @@ Scalar::SetValueFromData (DataExtractor
 if (data.GetByteOrder() == eByteOrderBig)
 {
 int128.x[1] = (uint64_t)data.GetU64 (&offset);
-int128.x[0] = (uint64_t)data.GetU64 (&offset + 1);
+int128.x[0] = (uint64_t)data.GetU64 (&offset);
 }
 else
 {
 int128.x[0] = (uint64_t)data.GetU64 (&offset);
-int128.x[1] = (uint64_t)data.GetU64 (&offset + 1);
+int128.x[1] = (uint64_t)data.GetU64 (&offset);
 }
 operator=(llvm::APInt(BITWIDTH_INT128, NUM_OF_WORDS_INT128, 
int128.x));
 break;
@@ -2665,16 +2665,16 @@ Scalar::SetValueFromData (DataExtractor
 if (data.GetByteOrder() == eByteOrderBig)
 {
 int256.x[3] = (uint64_t)data.GetU64 (&offset);
-int256.x[2] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[1] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[0] = (uint64_t)data.GetU64 (&offset + 1);
+int256.x[2] = (uint64_t)data.GetU64 (&offset);
+int256.x[1] = (uint64_t)data.GetU64 (&offset);
+int256.x[0] = (uint64_t)data.GetU64 (&offset);
 }
 else
 {
 int256.x[0] = (uint64_t)data.GetU64 (&offset);
-int256.x[1] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[2] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[3] = (uint64_t)data.GetU64 (&offset + 1);
+int256.x[1] = (uint64_t)data.GetU64 (&offset);
+int256.x[2] = (uint64_t)data.GetU64 (&offset);
+int256.x[3] = (uint64_t)data.GetU64 (&offset);
 }
 operator=(llvm::APInt(BITWIDTH_INT256, NUM_OF_WORDS_INT256, 
int256.x));
 break;
@@ -2698,12 +2698,12 @@ Scalar::SetValueFromData (DataExtractor
 if (data.GetByteOrder() == eByteOrderBig)
 {
 int128.x[1] = (uint64_t)data.GetU64 (&offset);
-int128.x[0] = (uint64_t)data.GetU64 (&offset + 1);
+int128.x[0] = (uint64_t)data.GetU64 (&offset);
 }
 else
 {
 int128.x[0] = (uint64_t)data.GetU64 (&offset);
-int128.x[1] = (uint64_t)data.GetU64 (&offset + 1);
+int128.x[1] = (uint64_t)data.GetU64 (&offset);
 }
 operator=(llvm::APInt(BITWIDTH_INT128, NUM_OF_WORDS_INT128, 
int128.x));
 break;
@@ -2711,16 +2711,16 @@ Scalar::SetValueFromData (DataExtractor
 if (data.GetByteOrder() == eByteOrderBig)
 {
 int256.x[3] = (uint64_t)data.GetU64 (&offset);
-int256.x[2] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[1] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[0] = (uint64_t)data.GetU64 (&offset + 1);
+int256.x[2] = (uint64_t)data.GetU64 (&offset);
+int256.x[1] = (uint64_t)data.GetU64 (&offset);
+int256.x[0] = (uint64_t)data.GetU64 (&offset);
 }
 else
 {
 int256.x[0] = (uint64_t)data.GetU64 (&offset);
-int256.x[1] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[2] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[3] = (uint64_t)data.GetU64 (&offset + 1);
+int256.x[1] = (uint64_t)data.GetU64 (&offset);
+int256.x[2] = (uint64_t)data.GetU64 (&offset);
+int256.x[3] = (uint64_t)data.GetU64 (&offset);
 }
 operator=(llvm::APInt(BITWIDTH_INT256, NUM_OF_WORDS_INT256, 
int256.x));
 break;


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

[Lldb-commits] [lldb] r266419 - Fix Scalar::MakeSigned for 128- and 256-bit types.

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Fri Apr 15 04:15:22 2016
New Revision: 266419

URL: http://llvm.org/viewvc/llvm-project?rev=266419&view=rev
Log:
Fix Scalar::MakeSigned for 128- and 256-bit types.

Obvious fix for incorrect result types of the operation.

Originally committed as part of (now reverted) r266311.


Modified:
lldb/trunk/source/Core/Scalar.cpp

Modified: lldb/trunk/source/Core/Scalar.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Scalar.cpp?rev=266419&r1=266418&r2=266419&view=diff
==
--- lldb/trunk/source/Core/Scalar.cpp (original)
+++ lldb/trunk/source/Core/Scalar.cpp Fri Apr 15 04:15:22 2016
@@ -1369,9 +1369,9 @@ Scalar::MakeSigned ()
 case e_slonglong:   success = true; break;
 case e_ulonglong:   m_type = e_slonglong;   success = true; break;
 case e_sint128: success = true; break;
-case e_uint128: m_type = e_sint;success = true; break;
+case e_uint128: m_type = e_sint128; success = true; break;
 case e_sint256: success = true; break;
-case e_uint256: m_type = e_sint;success = true; break;
+case e_uint256: m_type = e_sint256; success = true; break;
 case e_float:   success = true; break;
 case e_double:  success = true; break;
 case e_long_double: success = true; break;


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

[Lldb-commits] [lldb] r266417 - Fix ABISysV_s390x::GetArgumentValues

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Fri Apr 15 04:14:32 2016
New Revision: 266417

URL: http://llvm.org/viewvc/llvm-project?rev=266417&view=rev
Log:
Fix ABISysV_s390x::GetArgumentValues

This routine contained a stray "return false;" making part of the code
never executed.  Also, the stack offset where to find on-stack arguments
was incorrect.


Modified:
lldb/trunk/source/Plugins/ABI/SysV-s390x/ABISysV_s390x.cpp

Modified: lldb/trunk/source/Plugins/ABI/SysV-s390x/ABISysV_s390x.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ABI/SysV-s390x/ABISysV_s390x.cpp?rev=266417&r1=266416&r2=266417&view=diff
==
--- lldb/trunk/source/Plugins/ABI/SysV-s390x/ABISysV_s390x.cpp (original)
+++ lldb/trunk/source/Plugins/ABI/SysV-s390x/ABISysV_s390x.cpp Fri Apr 15 
04:14:32 2016
@@ -365,7 +365,7 @@ ABISysV_s390x::GetArgumentValues(Thread
 if (!sp)
 return false;
 
-addr_t current_stack_argument = sp;
+addr_t current_stack_argument = sp + 160;
 
 uint32_t argument_register_ids[5];
 
@@ -382,7 +382,6 @@ ABISysV_s390x::GetArgumentValues(Thread
 
 unsigned int current_argument_register = 0;
 
-return false;
 for (value_index = 0; value_index < num_values; ++value_index)
 {
 Value *value = values.GetValueAtIndex(value_index);


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

Re: [Lldb-commits] [PATCH] D18978: Support Linux on SystemZ as platform

[Ulrich Weigand via lldb-commits]

Ulrich Weigand/Germany/IBM wrote on 14.04.2016 18:20:20:

> So there seem to be at least two different issues, looking at the build
bot
> logs.   After the main SystemZ patch went it, there was just a single
> failure, a timeout on the new s390x.core test.  I guess we can just
disable
> that test until we know what's going on here.
>
> After the rest of the patches went in, we're additionally seeing all
those
> 32-bit failures.  Not sure which of the patches is responsible (most
likely
> the Scalar / APInt patch, just from the amount of changes).
>
> I'm currently rebuilding the Intel LLDB to see if I can reproduce
locally.

The current status is:

- I've disabled the s390x.core test on all architectures except s390x;
  there seems to be some problem with reading cross-architecture cores.

- There was a regression introduced due to a thinko in my gnu_libstdcpp.py
  patch; I've checked in a fix for that.

- Support for the new files was missing in the XCode project file;
  Greg checked in a fix for that.  Thanks!

- I was unable to reproduce the 32-bit failures on my system, so I just
  reverted the Scalar / APInt patch, and that got the build bot going
again.
  Looking at the results, I think I now understand why I wasn't able to
  reproduce: I was using gcc to compile the test cases, but apparently
  the failure occurred only when using clang.  I'll try again to reproduce.

Right now, the build bots seem to be going green again one by one,
hopefully
we'll be back to normal soon.  Sorry for the breakage!

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

[Lldb-commits] [lldb] r266352 - Fix regression in gnu_libstdcpp.py introduced by r266313

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Thu Apr 14 13:31:12 2016
New Revision: 266352

URL: http://llvm.org/viewvc/llvm-project?rev=266352&view=rev
Log:
Fix regression in gnu_libstdcpp.py introduced by r266313

CreateChildAtOffset needs a byte offset, not an element number.


Modified:
lldb/trunk/examples/synthetic/gnu_libstdcpp.py

Modified: lldb/trunk/examples/synthetic/gnu_libstdcpp.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/examples/synthetic/gnu_libstdcpp.py?rev=266352&r1=266351&r2=266352&view=diff
==
--- lldb/trunk/examples/synthetic/gnu_libstdcpp.py (original)
+++ lldb/trunk/examples/synthetic/gnu_libstdcpp.py Thu Apr 14 13:31:12 2016
@@ -239,7 +239,7 @@ class StdVectorSynthProvider:
return None
element_type = self.start_p.GetType().GetPointeeType()
element_bits = 8 * element_type.GetByteSize()
-   element_offset = index / element_bits
+   element_offset = (index / element_bits) * 
element_type.GetByteSize()
bit_offset = index % element_bits
element = 
self.start_p.CreateChildAtOffset('['+str(index)+']',element_offset,element_type)
bit = element.GetValueAsUnsigned(0) & (1 << bit_offset)


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

[Lldb-commits] [lldb] r266343 - Disable LinuxCoreTestCase.test_s390x

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Thu Apr 14 12:36:41 2016
New Revision: 266343

URL: http://llvm.org/viewvc/llvm-project?rev=266343&view=rev
Log:
Disable LinuxCoreTestCase.test_s390x

This seems to hang on non-s390x hosts.  Disable for now to get the build
bots going again.


Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py?rev=266343&r1=266342&r2=266343&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py
 Thu Apr 14 12:36:41 2016
@@ -30,6 +30,8 @@ class LinuxCoreTestCase(TestBase):
 """Test that lldb can read the process information from an x86_64 
linux core file."""
 self.do_test("x86_64", self._x86_64_pid)
 
+# This seems to hang on non-s390x platforms for some reason.  Disabling 
for now.
+@skipIf(archs=no_match(['s390x'])) 
 def test_s390x(self):
 """Test that lldb can read the process information from an s390x linux 
core file."""
 self.do_test("s390x", self._s390x_pid)


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

[Lldb-commits] [lldb] r266341 - Revert r266311 - Fix usage of APInt.getRawData for big-endian systems

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Thu Apr 14 12:22:18 2016
New Revision: 266341

URL: http://llvm.org/viewvc/llvm-project?rev=266341&view=rev
Log:
Revert r266311 - Fix usage of APInt.getRawData for big-endian systems

Try to get 32-bit build bots running again.


Modified:
lldb/trunk/include/lldb/Core/Scalar.h
lldb/trunk/include/lldb/Symbol/Type.h
lldb/trunk/source/Core/Scalar.cpp
lldb/trunk/source/Expression/IRInterpreter.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
lldb/trunk/source/Symbol/ClangASTContext.cpp
lldb/trunk/unittests/Core/ScalarTest.cpp

Modified: lldb/trunk/include/lldb/Core/Scalar.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Scalar.h?rev=266341&r1=266340&r2=266341&view=diff
==
--- lldb/trunk/include/lldb/Core/Scalar.h (original)
+++ lldb/trunk/include/lldb/Core/Scalar.h Thu Apr 14 12:22:18 2016
@@ -162,9 +162,6 @@ public:
 bool
 MakeSigned ();
 
-bool
-MakeUnsigned ();
-
 static const char *
 GetValueTypeAsCString (Scalar::Type value_type);
 
@@ -242,10 +239,22 @@ public:
 int
 SInt(int fail_value = 0) const;
 
+// Return the raw unsigned integer without any casting or conversion
+unsigned int
+RawUInt () const;
+
+// Return the raw unsigned long without any casting or conversion
+unsigned long
+RawULong () const;
+
+// Return the raw unsigned long long without any casting or conversion
+unsigned long long
+RawULongLong () const;
+
 unsigned char
 UChar(unsigned char fail_value = 0) const;
 
-signed char
+char
 SChar(char fail_value = 0) const;
 
 unsigned short
@@ -290,6 +299,9 @@ public:
 long double
 LongDouble(long double fail_value = 0.0) const;
 
+uint64_t
+GetRawBits64 (uint64_t fail_value) const;
+
 Error
 SetValueFromCString (const char *s, lldb::Encoding encoding, size_t 
byte_size);
 

Modified: lldb/trunk/include/lldb/Symbol/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/Type.h?rev=266341&r1=266340&r2=266341&view=diff
==
--- lldb/trunk/include/lldb/Symbol/Type.h (original)
+++ lldb/trunk/include/lldb/Symbol/Type.h Thu Apr 14 12:22:18 2016
@@ -958,13 +958,13 @@ public:
 uint64_t
 GetValueAsUnsigned () const
 {
-return m_value.getZExtValue();
+return *m_value.getRawData();
 }
 
 int64_t
 GetValueAsSigned () const
 {
-return m_value.getSExtValue();
+return (int64_t) *m_value.getRawData();
 }
 
 protected:

Modified: lldb/trunk/source/Core/Scalar.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Scalar.cpp?rev=266341&r1=266340&r2=266341&view=diff
==
--- lldb/trunk/source/Core/Scalar.cpp (original)
+++ lldb/trunk/source/Core/Scalar.cpp Thu Apr 14 12:22:18 2016
@@ -16,8 +16,6 @@
 #include 
 
 // Other libraries and framework includes
-#include "llvm/ADT/SmallString.h"
-
 // Project includes
 #include "lldb/Interpreter/Args.h"
 #include "lldb/Core/Error.h"
@@ -136,10 +134,10 @@ bool
 Scalar::GetData (DataExtractor &data, size_t limit_byte_size) const
 {
 size_t byte_size = GetByteSize();
+static float f_val;
+static double d_val;
 if (byte_size > 0)
 {
-const uint8_t *bytes = reinterpret_cast(GetBytes());
-
 if (limit_byte_size < byte_size)
 {
 if (endian::InlHostByteOrder() == eByteOrderLittle)
@@ -147,19 +145,105 @@ Scalar::GetData (DataExtractor &data, si
 // On little endian systems if we want fewer bytes from the
 // current type we just specify fewer bytes since the LSByte
 // is first...
-byte_size = limit_byte_size;
+switch(m_type)
+{
+case e_void:
+break;
+case e_sint:
+case e_uint:
+case e_slong:
+case e_ulong:
+case e_slonglong:
+case e_ulonglong:
+case e_sint128:
+case e_uint128:
+case e_sint256:
+case e_uint256:
+data.SetData((const uint8_t *)m_integer.getRawData(), 
limit_byte_size, endian::InlHostByteOrder());
+return true;
+case e_float:
+f_val = m_float.convertToFloat();
+data.SetData((uint8_t *)&f_val, limit_byte_size, 
endian::InlHostByteOrder());
+return true;
+case e_double:
+d_val = m_float.convertToDouble();
+data.SetData((uint8_t *)&d_val, limit_byte_size, 
endian::InlHostByteOrder());
+return true;
+

Re: [Lldb-commits] [PATCH] D18978: Support Linux on SystemZ as platform

[Ulrich Weigand via lldb-commits]

Pavel Labath  wrote on 14.04.2016 17:36:40:

> this has broken basically everything on 32-bit targets
>
 >.
> Will you be able to track down the problem quickly? I don't expect the
> fix to be complicated, but if we can't track it down quickly (1-2
> hours?) we should start pulling out the offending changes...

So there seem to be at least two different issues, looking at the build bot
logs.   After the main SystemZ patch went it, there was just a single
failure, a timeout on the new s390x.core test.  I guess we can just disable
that test until we know what's going on here.

After the rest of the patches went in, we're additionally seeing all those
32-bit failures.  Not sure which of the patches is responsible (most likely
the Scalar / APInt patch, just from the amount of changes).

I'm currently rebuilding the Intel LLDB to see if I can reproduce locally.

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

Re: [Lldb-commits] [PATCH] D18978: Support Linux on SystemZ as platform

[Ulrich Weigand via lldb-commits]

Pavel Labath  wrote on 14.04.2016 17:36:40:

> this has broken basically everything on 32-bit targets
>
 >.
> Will you be able to track down the problem quickly? I don't expect the
> fix to be complicated, but if we can't track it down quickly (1-2
> hours?) we should start pulling out the offending changes...

Huh, sorry for that.  I did test x86_64, but not 32-bit.

I'll have a look and see what I can find.

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

Re: [Lldb-commits] [PATCH] D18978: Support Linux on SystemZ as platform

[Ulrich Weigand via lldb-commits]

uweigand added a comment.

In http://reviews.llvm.org/D18978#400787, @labath wrote:

> That's perfect, thanks a lot. :)
>
> Do you have commit access? If not, let me know when you're ready to start 
> landing these things...


I do have commit access, and have committed the 10 out of 12 patches that are 
approved as of today.  This means current mainline should support Linux on 
SystemZ as target pretty well.  Due to the two patches still missing, I'm still 
seeing three test suite failures: TestNoreturnUnwind.py and 
TestInferiorAssert.py fail due to missing http://reviews.llvm.org/D18975, and 
TestCppScope.py fails due to missing http://reviews.llvm.org/D18976.

Otherwise, everything is looking good.   Thanks to everybody for your support 
in getting this in!


Repository:
  rL LLVM

http://reviews.llvm.org/D18978



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

[Lldb-commits] [lldb] r266311 - Fix usage of APInt.getRawData for big-endian systems

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Thu Apr 14 09:32:01 2016
New Revision: 266311

URL: http://llvm.org/viewvc/llvm-project?rev=266311&view=rev
Log:
Fix usage of APInt.getRawData for big-endian systems

The Scalar implementation and a few other places in LLDB directly
access the internal implementation of APInt values using the
getRawData method.  Unfortunately, pretty much all of these places
do not handle big-endian systems correctly.  While on little-endian
machines, the pointer returned by getRawData can simply be used as
a pointer to the integer value in its natural format, no matter
what size, this is not true on big-endian systems: getRawData
actually points to an array of type uint64_t, with the first element
of the array always containing the least-significant word of the
integer.  This means that if the bitsize of that integer is smaller
than 64, we need to add an offset to the pointer returned by
getRawData in order to access the value in its natural type, and
if the bitsize is *larger* than 64, we actually have to swap the
constituent words before we can access the value in its natural type.

This patch fixes every incorrect use of getRawData in the code base.
For the most part, this is done by simply removing uses of getRawData
in the first place, and using other APInt member functions to operate
on the integer data.

This can be done in many member functions of Scalar itself, as well
as in Symbol/Type.h and in IRInterpreter::Interpret.  For the latter,
I've had to add a Scalar::MakeUnsigned routine to parallel the existing
Scalar::MakeSigned, e.g. in order to implement an unsigned divide.

The Scalar::RawUInt, Scalar::RawULong, and Scalar::RawULongLong
were already unused and can be simply removed.  I've also removed
the Scalar::GetRawBits64 function and its few users.

The one remaining user of getRawData in Scalar.cpp is GetBytes.
I've implemented all the cases described above to correctly
implement access to the underlying integer data on big-endian
systems.  GetData now simply calls GetBytes instead of reimplementing
its contents.

Finally, two places in the clang interface code were also accessing
APInt.getRawData in order to actually construct a byte representation
of an integer.  I've changed those to make use of a Scalar instead,
to avoid having to re-implement the logic there.

The patch also adds a couple of unit tests verifying correct operation
of the GetBytes routine as well as the conversion routines.  Those tests
actually exposed more problems in the Scalar code: the SetValueFromData
routine didn't work correctly for 128- and 256-bit data types, and the
SChar routine should have an explicit "signed char" return type to work
correctly on platforms where char defaults to unsigned.

Differential Revision: http://reviews.llvm.org/D18981


Modified:
lldb/trunk/include/lldb/Core/Scalar.h
lldb/trunk/include/lldb/Symbol/Type.h
lldb/trunk/source/Core/Scalar.cpp
lldb/trunk/source/Expression/IRInterpreter.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
lldb/trunk/source/Symbol/ClangASTContext.cpp
lldb/trunk/unittests/Core/ScalarTest.cpp

Modified: lldb/trunk/include/lldb/Core/Scalar.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Scalar.h?rev=266311&r1=266310&r2=266311&view=diff
==
--- lldb/trunk/include/lldb/Core/Scalar.h (original)
+++ lldb/trunk/include/lldb/Core/Scalar.h Thu Apr 14 09:32:01 2016
@@ -162,6 +162,9 @@ public:
 bool
 MakeSigned ();
 
+bool
+MakeUnsigned ();
+
 static const char *
 GetValueTypeAsCString (Scalar::Type value_type);
 
@@ -239,22 +242,10 @@ public:
 int
 SInt(int fail_value = 0) const;
 
-// Return the raw unsigned integer without any casting or conversion
-unsigned int
-RawUInt () const;
-
-// Return the raw unsigned long without any casting or conversion
-unsigned long
-RawULong () const;
-
-// Return the raw unsigned long long without any casting or conversion
-unsigned long long
-RawULongLong () const;
-
 unsigned char
 UChar(unsigned char fail_value = 0) const;
 
-char
+signed char
 SChar(char fail_value = 0) const;
 
 unsigned short
@@ -299,9 +290,6 @@ public:
 long double
 LongDouble(long double fail_value = 0.0) const;
 
-uint64_t
-GetRawBits64 (uint64_t fail_value) const;
-
 Error
 SetValueFromCString (const char *s, lldb::Encoding encoding, size_t 
byte_size);
 

Modified: lldb/trunk/include/lldb/Symbol/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/Type.h?rev=266311&r1=266310&r2=266311&view=diff
==
--- lldb/trunk/include/lldb/Symbol/Type.h (original)
+++ lldb/trunk/include/lldb/Symbol/Type.h Thu Apr 14 09:32:01 2016
@@ -958,13 +958,13 @@ public:
 uint64_t
 GetValueAsUnsigned () cons

Re: [Lldb-commits] [PATCH] D18981: Fix usage of APInt.getRawData for big-endian systems

[Ulrich Weigand via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL266311: Fix usage of APInt.getRawData for big-endian systems 
(authored by uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18981?vs=53622&id=53710#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18981

Files:
  lldb/trunk/include/lldb/Core/Scalar.h
  lldb/trunk/include/lldb/Symbol/Type.h
  lldb/trunk/source/Core/Scalar.cpp
  lldb/trunk/source/Expression/IRInterpreter.cpp
  lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
  lldb/trunk/source/Symbol/ClangASTContext.cpp
  lldb/trunk/unittests/Core/ScalarTest.cpp

Index: lldb/trunk/unittests/Core/ScalarTest.cpp
===
--- lldb/trunk/unittests/Core/ScalarTest.cpp
+++ lldb/trunk/unittests/Core/ScalarTest.cpp
@@ -15,7 +15,10 @@
 
 #include "gtest/gtest.h"
 
+#include "lldb/Core/Error.h"
 #include "lldb/Core/Scalar.h"
+#include "lldb/Core/DataExtractor.h"
+#include "lldb/Host/Endian.h"
 
 using namespace lldb_private;
 
@@ -30,3 +33,49 @@
 ASSERT_EQ(a >> c, a_scalar >> c_scalar);
 ASSERT_EQ(b >> c, b_scalar >> c_scalar);
 }
+
+TEST(ScalarTest, GetBytes)
+{
+int a = 0x01020304;
+long long b = 0x0102030405060708LL;
+float c = 1234567.89e42;
+double d = 1234567.89e42;
+char e[16] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 };
+char f[32] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
+   17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32 };
+Scalar a_scalar(a);
+Scalar b_scalar(b);
+Scalar c_scalar(c);
+Scalar d_scalar(d);
+Scalar e_scalar;
+Scalar f_scalar;
+DataExtractor e_data(e, sizeof(e), endian::InlHostByteOrder(), sizeof(void *));
+Error e_error = e_scalar.SetValueFromData(e_data, lldb::eEncodingUint, sizeof(e));
+DataExtractor f_data(f, sizeof(f), endian::InlHostByteOrder(), sizeof(void *));
+Error f_error = f_scalar.SetValueFromData(f_data, lldb::eEncodingUint, sizeof(f));
+ASSERT_EQ(0, memcmp(&a, a_scalar.GetBytes(), sizeof(a)));
+ASSERT_EQ(0, memcmp(&b, b_scalar.GetBytes(), sizeof(b)));
+ASSERT_EQ(0, memcmp(&c, c_scalar.GetBytes(), sizeof(c)));
+ASSERT_EQ(0, memcmp(&d, d_scalar.GetBytes(), sizeof(d)));
+ASSERT_EQ(0, e_error.Fail());
+ASSERT_EQ(0, memcmp(e, e_scalar.GetBytes(), sizeof(e)));
+ASSERT_EQ(0, f_error.Fail());
+ASSERT_EQ(0, memcmp(f, f_scalar.GetBytes(), sizeof(f)));
+}
+
+TEST(ScalarTest, CastOperations)
+{
+long long a = 0xf1f2f3f4f5f6f7f8LL;
+Scalar a_scalar(a);
+ASSERT_EQ((signed char)a, a_scalar.SChar());
+ASSERT_EQ((unsigned char)a, a_scalar.UChar());
+ASSERT_EQ((signed short)a, a_scalar.SShort());
+ASSERT_EQ((unsigned short)a, a_scalar.UShort());
+ASSERT_EQ((signed int)a, a_scalar.SInt());
+ASSERT_EQ((unsigned int)a, a_scalar.UInt());
+ASSERT_EQ((signed long)a, a_scalar.SLong());
+ASSERT_EQ((unsigned long)a, a_scalar.ULong());
+ASSERT_EQ((signed long long)a, a_scalar.SLongLong());
+ASSERT_EQ((unsigned long long)a, a_scalar.ULongLong());
+}
+
Index: lldb/trunk/source/Symbol/ClangASTContext.cpp
===
--- lldb/trunk/source/Symbol/ClangASTContext.cpp
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp
@@ -72,6 +72,7 @@
 #include "lldb/Core/Module.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/RegularExpression.h"
+#include "lldb/Core/Scalar.h"
 #include "lldb/Core/StreamFile.h"
 #include "lldb/Core/ThreadSafeDenseMap.h"
 #include "lldb/Core/UniqueCStringMap.h"
@@ -8645,18 +8646,10 @@
 const uint64_t byte_size = bit_size / 8;
 if (dst_size >= byte_size)
 {
-if (bit_size == sizeof(float)*8)
-{
-float float32 = ap_float.convertToFloat();
-::memcpy (dst, &float32, byte_size);
+Scalar scalar = ap_float.bitcastToAPInt().zextOrTrunc(llvm::NextPowerOf2(byte_size) * 8);
+lldb_private::Error get_data_error;
+if (scalar.GetAsMemoryData(dst, byte_size, lldb_private::endian::InlHostByteOrder(), get_data_error))
 return byte_size;
-}
-else if (bit_size >= 64)
-{
-llvm::APInt ap_int(ap_float.bitcastToAPInt());
-::memcpy (dst, ap_int.getRawData(), byte_size);
-return byte_size;
-}
 }
 }
 }
Index: lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
===
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
@@ -1105,7 +1105,13 @@
 
 if (ConstantInt *int_initializer = dyn_cast(initializer))
 {
-memcpy (data, i

Re: [Lldb-commits] [PATCH] D18980: Make Scalar::GetBytes and RegisterValue::GetBytes const

[Ulrich Weigand via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL266310: Make Scalar::GetBytes and RegisterValue::GetBytes 
const (authored by uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18980?vs=53295&id=53709#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18980

Files:
  lldb/trunk/include/lldb/Core/RegisterValue.h
  lldb/trunk/include/lldb/Core/Scalar.h
  lldb/trunk/source/Core/RegisterValue.cpp
  lldb/trunk/source/Core/Scalar.cpp
  lldb/trunk/source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
  lldb/trunk/source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp

Index: lldb/trunk/source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
===
--- lldb/trunk/source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
+++ lldb/trunk/source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
@@ -2603,7 +2603,7 @@
 bool success = false, branch_hit = true;
 int32_t target = 0;
 RegisterValue reg_value;
-uint8_t * ptr = NULL;
+const uint8_t *ptr = NULL;
 
 uint32_t wt = m_reg_info->getEncodingValue (insn.getOperand(0).getReg());
 int32_t offset = insn.getOperand(1).getImm();
@@ -2613,7 +2613,7 @@
 return false;
 
 if (ReadRegister (eRegisterKindDWARF, dwarf_w0_mips + wt, reg_value))
-ptr = (uint8_t *)reg_value.GetBytes();
+ptr = (const uint8_t *)reg_value.GetBytes();
 else
 return false;
 
@@ -2626,15 +2626,15 @@
 branch_hit = false;
 break;
 case 2:
-if((*(uint16_t *)ptr == 0 && bnz) || (*(uint16_t *)ptr != 0 && !bnz))
+if ((*(const uint16_t *)ptr == 0 && bnz) || (*(const uint16_t *)ptr != 0 && !bnz))
 branch_hit = false;
 break;
 case 4:
-if((*(uint32_t *)ptr == 0 && bnz) || (*(uint32_t *)ptr != 0 && !bnz))
+if ((*(const uint32_t *)ptr == 0 && bnz) || (*(const uint32_t *)ptr != 0 && !bnz))
 branch_hit = false;
 break;
 case 8:
-if((*(uint64_t *)ptr == 0 && bnz) || (*(uint64_t *)ptr != 0 && !bnz))
+if ((*(const uint64_t *)ptr == 0 && bnz) || (*(const uint64_t *)ptr != 0 && !bnz))
 branch_hit = false;
 break;
 }
Index: lldb/trunk/source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp
===
--- lldb/trunk/source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp
+++ lldb/trunk/source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp
@@ -1874,7 +1874,7 @@
 bool success = false, branch_hit = true;
 int64_t target = 0;
 RegisterValue reg_value;
-uint8_t * ptr = NULL;
+const uint8_t *ptr = NULL;
 
 uint32_t wt = m_reg_info->getEncodingValue (insn.getOperand(0).getReg());
 int64_t offset = insn.getOperand(1).getImm();
@@ -1884,7 +1884,7 @@
 return false;
 
 if (ReadRegister (eRegisterKindDWARF, dwarf_w0_mips64 + wt, reg_value))
-ptr = (uint8_t *)reg_value.GetBytes();
+ptr = (const uint8_t *)reg_value.GetBytes();
 else
 return false;
 
@@ -1897,15 +1897,15 @@
 branch_hit = false;
 break;
 case 2:
-if((*(uint16_t *)ptr == 0 && bnz) || (*(uint16_t *)ptr != 0 && !bnz))
+if ((*(const uint16_t *)ptr == 0 && bnz) || (*(const uint16_t *)ptr != 0 && !bnz))
 branch_hit = false;
 break;
 case 4:
-if((*(uint32_t *)ptr == 0 && bnz) || (*(uint32_t *)ptr != 0 && !bnz))
+if ((*(const uint32_t *)ptr == 0 && bnz) || (*(const uint32_t *)ptr != 0 && !bnz))
 branch_hit = false;
 break;
 case 8:
-if((*(uint64_t *)ptr == 0 && bnz) || (*(uint64_t *)ptr != 0 && !bnz))
+if ((*(const uint64_t *)ptr == 0 && bnz) || (*(const uint64_t *)ptr != 0 && !bnz))
 branch_hit = false;
 break;
 }
Index: lldb/trunk/source/Core/RegisterValue.cpp
===
--- lldb/trunk/source/Core/RegisterValue.cpp
+++ lldb/trunk/source/Core/RegisterValue.cpp
@@ -203,34 +203,13 @@
 // Use a data extractor to correctly copy and pad the bytes read into the
 // register value
 DataExtractor src_data (src, src_len, src_byte_order, 4);
-
-// Given the register info, set the value type of this RegisterValue object
-SetType (reg_info);
-// And make sure we were able to figure out what that register value was
-RegisterValue::Type value_type = GetType();
-if (value_type == eTypeInvalid)
-{
-// No value has been read into this object...
-error.SetErrorStringWithFo

Re: [Lldb-commits] [PATCH] D18973: Find .plt section in object files generated by recent ld

[Ulrich Weigand via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL266316: Find .plt section in object files generated by 
recent ld (authored by uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18973?vs=53288&id=53715#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18973

Files:
  lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp

Index: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -2611,17 +2611,17 @@
 {
 assert(rel_hdr->sh_type == SHT_RELA || rel_hdr->sh_type == SHT_REL);
 
-// The link field points to the associated symbol table. The info field
-// points to the section holding the plt.
+// The link field points to the associated symbol table.
 user_id_t symtab_id = rel_hdr->sh_link;
-user_id_t plt_id = rel_hdr->sh_info;
 
 // If the link field doesn't point to the appropriate symbol name table 
then
 // try to find it by name as some compiler don't fill in the link fields.
 if (!symtab_id)
 symtab_id = GetSectionIndexByName(".dynsym");
-if (!plt_id)
-plt_id = GetSectionIndexByName(".plt");
+
+// Get PLT section.  We cannot use rel_hdr->sh_info, since current linkers
+// point that to the .got.plt or .got section instead of .plt.
+user_id_t plt_id = GetSectionIndexByName(".plt");
 
 if (!symtab_id || !plt_id)
 return 0;


Index: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -2611,17 +2611,17 @@
 {
 assert(rel_hdr->sh_type == SHT_RELA || rel_hdr->sh_type == SHT_REL);
 
-// The link field points to the associated symbol table. The info field
-// points to the section holding the plt.
+// The link field points to the associated symbol table.
 user_id_t symtab_id = rel_hdr->sh_link;
-user_id_t plt_id = rel_hdr->sh_info;
 
 // If the link field doesn't point to the appropriate symbol name table then
 // try to find it by name as some compiler don't fill in the link fields.
 if (!symtab_id)
 symtab_id = GetSectionIndexByName(".dynsym");
-if (!plt_id)
-plt_id = GetSectionIndexByName(".plt");
+
+// Get PLT section.  We cannot use rel_hdr->sh_info, since current linkers
+// point that to the .got.plt or .got section instead of .plt.
+user_id_t plt_id = GetSectionIndexByName(".plt");
 
 if (!symtab_id || !plt_id)
 return 0;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r266316 - Find .plt section in object files generated by recent ld

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Thu Apr 14 09:36:29 2016
New Revision: 266316

URL: http://llvm.org/viewvc/llvm-project?rev=266316&view=rev
Log:
Find .plt section in object files generated by recent ld

Code in ObjectFileELF::ParseTrampolineSymbols assumes that the sh_info
field of the .rel(a).plt section identifies the .plt section.

However, with recent GNU ld this is no longer true.  As a result of this:
https://sourceware.org/bugzilla/show_bug.cgi?id=18169
in object files generated with current linkers the sh_info field of
.rel(a).plt now points to the .got.plt section (or .got on some targets).

This causes LLDB to fail to identify any PLT stubs, causing a number of
test case failures.

This patch changes LLDB to simply always look for the .plt section by
name.  This should be safe across all linkers and targets.

Differential Revision: http://reviews.llvm.org/D18973


Modified:
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp

Modified: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp?rev=266316&r1=266315&r2=266316&view=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp Thu Apr 14 
09:36:29 2016
@@ -2611,17 +2611,17 @@ ObjectFileELF::ParseTrampolineSymbols(Sy
 {
 assert(rel_hdr->sh_type == SHT_RELA || rel_hdr->sh_type == SHT_REL);
 
-// The link field points to the associated symbol table. The info field
-// points to the section holding the plt.
+// The link field points to the associated symbol table.
 user_id_t symtab_id = rel_hdr->sh_link;
-user_id_t plt_id = rel_hdr->sh_info;
 
 // If the link field doesn't point to the appropriate symbol name table 
then
 // try to find it by name as some compiler don't fill in the link fields.
 if (!symtab_id)
 symtab_id = GetSectionIndexByName(".dynsym");
-if (!plt_id)
-plt_id = GetSectionIndexByName(".plt");
+
+// Get PLT section.  We cannot use rel_hdr->sh_info, since current linkers
+// point that to the .got.plt or .got section instead of .plt.
+user_id_t plt_id = GetSectionIndexByName(".plt");
 
 if (!symtab_id || !plt_id)
 return 0;


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

Re: [Lldb-commits] [PATCH] D18985: Fix test cases for big-endian systems

[Ulrich Weigand via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL266315: Fix test cases for big-endian systems (authored by 
uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18985?vs=53501&id=53714#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18985

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/main.cpp
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-smart-array/TestDataFormatterSmartArray.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/synthcapping/TestSyntheticCapping.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/synthcapping/main.cpp
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/memory/cache/TestMemoryCache.py
  
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
  lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
  lldb/trunk/packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py

Index: lldb/trunk/packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
@@ -186,7 +186,10 @@
 
 self.assertTrue(new_object.GetValue() == "1", 'new_object == 1')
 
-data.SetData(error, 'A\0\0\0', data.GetByteOrder(), data.GetAddressByteSize())
+if data.GetByteOrder() == lldb.eByteOrderBig:
+data.SetData(error, '\0\0\0A', data.GetByteOrder(), data.GetAddressByteSize())
+else:
+data.SetData(error, 'A\0\0\0', data.GetByteOrder(), data.GetAddressByteSize())
 self.assertTrue(error.Success())
 
 data2 = lldb.SBData()
@@ -311,8 +314,8 @@
 self.assert_data(data2.GetSignedInt32, 4, -2)
 
 data2.SetDataFromSInt64Array([2, -2])
-self.assert_data(data2.GetSignedInt32, 0, 2)
-self.assert_data(data2.GetSignedInt32, 8, -2)
+self.assert_data(data2.GetSignedInt64, 0, 2)
+self.assert_data(data2.GetSignedInt64, 8, -2)
 
 data2.SetDataFromUInt32Array([1,2,3,4,5])
 self.assert_data(data2.GetUnsignedInt32, 0, 1)
Index: lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
@@ -232,6 +232,7 @@
 
 # The bytearray_to_int utility function expects a little endian bytearray.
 if byteOrder == lldb.eByteOrderBig:
+content = bytearray(content, 'ascii')
 content.reverse()
 
 new_value = bytearray_to_int(content, byteSize)
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
@@ -19,7 +19,13 @@
 
 self.runCmd("process launch", RUN_SUCCEEDED)
 
-self.expect('frame variable -f x i', substrs=['ff41'])
+process = self.dbg.GetSelectedTarget().GetProcess()
+
+if process.GetByteOrder() == lldb.eByteOrderLittle:
+self.expect('frame variable -f x i', substrs=['ff41'])
+else:
+self.expect('frame variable -f x i', substrs=['4100'])
+
 self.expect('frame variable c', substrs=["'A"])
 
 self.expect('frame variable x', matching=False, substrs=['3'])
Index: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
+++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
@@ -387,7 +387,10 @@
 return retval
 
 elif endian == 'big':
-retval = value.encode("hex")
+retval = ""
+while value != 0:
+retval = "{:02x}".format(value & 0xff) + retval
+value = value >> 8
 if byte_size:
 # Add zero-fill to the left/front (MSB side) of the value.
 retval = ("00" * (byte_size - len(retval)/2)) + retval
Index: lldb/trunk/

[Lldb-commits] [lldb] r266315 - Fix test cases for big-endian systems

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Thu Apr 14 09:35:02 2016
New Revision: 266315

URL: http://llvm.org/viewvc/llvm-project?rev=266315&view=rev
Log:
Fix test cases for big-endian systems

A number of test cases were failing on big-endian systems simply due to
byte order assumptions in the tests themselves, and no underlying bug
in LLDB.

These two test cases:
  tools/lldb-server/lldbgdbserverutils.py
  python_api/process/TestProcessAPI.py
actually check for big-endian target byte order, but contain Python errors
in the corresponding code paths.

These test cases:
  
functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
  
functionalities/data-formatter/data-formatter-smart-array/TestDataFormatterSmartArray.py
  functionalities/data-formatter/synthcapping/TestSyntheticCapping.py
  lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
  python_api/sbdata/TestSBData.py  (first change)
could be fixed to check for big-endian target byte order and update the
expected result strings accordingly.  For the two synthetic tests, I've
also updated the source to make sure the fake_a value is always nonzero
on both big- and little-endian platforms.

These test case:
  python_api/sbdata/TestSBData.py  (second change)
  functionalities/memory/cache/TestMemoryCache.py
simply accessed memory with the wrong size, which wasn't noticed on LE
but fails on BE.

Differential Revision: http://reviews.llvm.org/D18985


Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/main.cpp

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-smart-array/TestDataFormatterSmartArray.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/synthcapping/TestSyntheticCapping.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/synthcapping/main.cpp

lldb/trunk/packages/Python/lldbsuite/test/functionalities/memory/cache/TestMemoryCache.py

lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py

lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
lldb/trunk/packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py?rev=266315&r1=266314&r2=266315&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
 Thu Apr 14 09:35:02 2016
@@ -44,6 +44,8 @@ class PythonSynthDataFormatterTestCase(T
 
 self.runCmd("run", RUN_SUCCEEDED)
 
+process = self.dbg.GetSelectedTarget().GetProcess()
+
 # The stop reason of the thread should be breakpoint.
 self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
 substrs = ['stopped',
@@ -62,40 +64,46 @@ class PythonSynthDataFormatterTestCase(T
 
 # print the f00_1 variable without a synth
 self.expect("frame variable f00_1",
-substrs = ['a = 0',
-   'b = 1',
-   'r = 33']);
+substrs = ['a = 1',
+   'b = 2',
+   'r = 34']);
 
 # now set up the synth
 self.runCmd("script from fooSynthProvider import *")
 self.runCmd("type synth add -l fooSynthProvider foo")
 self.expect("type synthetic list foo", substrs=['fooSynthProvider'])
 
+# note that the value of fake_a depends on target byte order
+if process.GetByteOrder() == lldb.eByteOrderLittle:
+fake_a_val = 0x0200
+else:
+fake_a_val = 0x0100
+
 # check that we get the two real vars and the fake_a variables
 self.expect("frame variable f00_1",
-substrs = ['r = 33',
-   'fake_a = 16777216',
-   'a = 0']);
+substrs = ['r = 34',
+   'fake_a = %d' % fake_a_val,
+   'a = 1']);
 
 # check that we do not get the extra vars
 self.expect("frame variable f00_1", matching=False,
-substrs = ['b = 1']);
+  

Re: [Lldb-commits] [PATCH] D18984: Fix ARM instruction emulation tests on big-endian systems

[Ulrich Weigand via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL266314: Fix ARM instruction emulation tests on big-endian 
systems (authored by uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18984?vs=53500&id=53713#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18984

Files:
  lldb/trunk/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
  lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp
  lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.h

Index: lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.h
===
--- lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.h
+++ lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.h
@@ -30,10 +30,10 @@
 ReadPseudoRegisterValue (uint32_t reg_num, bool &success);
 
 bool
-StoreToPseudoAddress (lldb::addr_t p_address, uint64_t value, uint32_t size);
+StoreToPseudoAddress (lldb::addr_t p_address, uint32_t value);
 
 uint32_t
-ReadFromPseudoAddress (lldb::addr_t p_address, uint32_t size, bool &success);
+ReadFromPseudoAddress (lldb::addr_t p_address, bool &success);
 
 void
 ClearPseudoRegisters ();
@@ -82,11 +82,7 @@
 uint32_t m_gpr[17];
 struct _sd_regs
 {
-union 
-{
-uint32_t s_reg[2];
-uint64_t d_reg;
-} sd_regs[16];  // sregs 0 - 31 & dregs 0 - 15
+uint32_t s_regs[32]; // sregs 0 - 31 & dregs 0 - 15
 
 uint64_t d_regs[16]; // dregs 16-31
  
Index: lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp
===
--- lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp
+++ lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp
@@ -61,11 +61,15 @@
 
 if (reg_ctx->ReadRegister (reg_info, reg_value))
 {
+uint64_t value = reg_value.GetAsUInt64();
 uint32_t idx = i - dwarf_d0;
 if (i < 16)
-m_vfp_regs.sd_regs[idx].d_reg = reg_value.GetAsUInt64();
+{
+m_vfp_regs.s_regs[idx * 2] = (uint32_t)value;
+m_vfp_regs.s_regs[idx * 2 + 1] = (uint32_t)(value >> 32);
+}
 else
-m_vfp_regs.d_regs[idx - 16] = reg_value.GetAsUInt64();
+m_vfp_regs.d_regs[idx - 16] = value;
 }
 else
 success = false;
@@ -82,16 +86,18 @@
 else if ((dwarf_s0 <= reg_num) && (reg_num <= dwarf_s31))
 {
 uint32_t idx = reg_num - dwarf_s0;
-m_vfp_regs.sd_regs[idx / 2].s_reg[idx % 2] = (uint32_t) value;
+m_vfp_regs.s_regs[idx] = (uint32_t)value;
 }
 else if ((dwarf_d0 <= reg_num) && (reg_num <= dwarf_d31))
 {
-if ((reg_num - dwarf_d0) < 16)
+uint32_t idx = reg_num - dwarf_d0;
+if (idx < 16)
 {
-m_vfp_regs.sd_regs[reg_num - dwarf_d0].d_reg = value;
+m_vfp_regs.s_regs[idx * 2] = (uint32_t)value;
+m_vfp_regs.s_regs[idx * 2 + 1] = (uint32_t)(value >> 32);
 }
 else
-m_vfp_regs.d_regs[reg_num - dwarf_d16] = value;
+m_vfp_regs.d_regs[idx - 16] = value;
 }
 else
 return false;
@@ -110,14 +116,15 @@
 else if ((dwarf_s0 <= reg_num) && (reg_num <= dwarf_s31))
 {
 uint32_t idx = reg_num - dwarf_s0;
-value = m_vfp_regs.sd_regs[idx / 2].s_reg[idx % 2];
+value = m_vfp_regs.d_regs[idx];
 }
 else if ((dwarf_d0 <= reg_num) && (reg_num <= dwarf_d31))
 {
-if ((reg_num - dwarf_d0) < 16)
-value = m_vfp_regs.sd_regs[reg_num - dwarf_d0].d_reg;
+uint32_t idx = reg_num - dwarf_d0;
+if (idx < 16)
+value = (uint64_t)m_vfp_regs.s_regs[idx * 2] | ((uint64_t)m_vfp_regs.s_regs[idx * 2 + 1] >> 32);
 else
-value = m_vfp_regs.d_regs[reg_num - dwarf_d16];
+value = m_vfp_regs.d_regs[idx - 16];
 }
 else
 success = false;
@@ -131,8 +138,8 @@
 for (int i = 0; i < 17; ++i)
 m_gpr[i] = 0;
 
-for (int i = 0; i < 16; ++i)
-m_vfp_regs.sd_regs[i].d_reg = 0;
+for (int i = 0; i < 32; ++i)
+m_vfp_regs.s_regs[i] = 0;
 
 for (int i = 0; i < 16; ++i)
 m_vfp_regs.d_regs[i] = 0;
@@ -145,23 +152,14 @@
 }
 
 bool
-EmulationStateARM::StoreToPseudoAddress (lldb::addr_t p_address, uint64_t value, uint32_t size)
+EmulationStateARM::StoreToPseudoAddress (lldb::addr_t p_address, uint32_t value)
 {
-if (size > 8)
-return false;
-
-if (size <= 4)
-m_memory[p_address] = value;
-else if (size == 8)
-{
-m_memory[p_address] = (value << 32) >> 32;
-m_memory[p_address + 4] = value << 32;
-}
+m_memory[p_address] = value;
 return true;
 }
 
 uint32_t
-EmulationStateARM::ReadFromPseudoAddre

[Lldb-commits] [lldb] r266314 - Fix ARM instruction emulation tests on big-endian systems

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Thu Apr 14 09:34:19 2016
New Revision: 266314

URL: http://llvm.org/viewvc/llvm-project?rev=266314&view=rev
Log:
Fix ARM instruction emulation tests on big-endian systems

Running the ARM instruction emulation test on a big-endian system
would fail, since the code doesn't respect endianness properly.

In EmulateInstructionARM::TestEmulation, code assumes that an
instruction opcode read in from the test file is in target byte
order, but it was in fact read in in host byte order.

More difficult to fix, the EmulationStateARM structure models
the overlapping sregs and dregs by a union in _sd_regs.  This
only works correctly if the host is a little-endian system.
I've removed the union in favor of a simple array containing
the 32 sregs, and changed any code accessing dregs to explicitly
use the correct two sregs overlaying that dreg in the proper
target order.

Also, the EmulationStateARM::ReadPseudoMemory and WritePseudoMemory
track memory as a map of uint32_t values in host byte order, and
implement 64-bit memory accessing by splitting them up into two
uint32_t ones.  However, callers expect memory contents to be
provided in the form of a byte array (in target byte order).
This means the uint32_t contents need to be byte-swapped on
BE systems, and when splitting up a 64-bit access into two 32-bit
ones, byte order has to be respected.

Differential Revision: http://reviews.llvm.org/D18984


Modified:
lldb/trunk/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp
lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.h

Modified: lldb/trunk/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp?rev=266314&r1=266313&r2=266314&view=diff
==
--- lldb/trunk/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp 
(original)
+++ lldb/trunk/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp Thu Apr 
14 09:34:19 2016
@@ -13683,14 +13683,14 @@ EmulateInstructionARM::TestEmulation (St
 {
 m_opcode_mode = eModeThumb;
 if (test_opcode < 0x1)
-m_opcode.SetOpcode16 (test_opcode, GetByteOrder());
+m_opcode.SetOpcode16 (test_opcode, endian::InlHostByteOrder());
 else
-m_opcode.SetOpcode32 (test_opcode, GetByteOrder());
+m_opcode.SetOpcode32 (test_opcode, endian::InlHostByteOrder());
 }
 else if (arch.GetTriple().getArch() == llvm::Triple::arm)
 {
 m_opcode_mode = eModeARM;
-m_opcode.SetOpcode32 (test_opcode, GetByteOrder());
+m_opcode.SetOpcode32 (test_opcode, endian::InlHostByteOrder());
 }
 else
 {

Modified: lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp?rev=266314&r1=266313&r2=266314&view=diff
==
--- lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp (original)
+++ lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp Thu Apr 14 
09:34:19 2016
@@ -61,11 +61,15 @@ EmulationStateARM::LoadPseudoRegistersFr
 
 if (reg_ctx->ReadRegister (reg_info, reg_value))
 {
+uint64_t value = reg_value.GetAsUInt64();
 uint32_t idx = i - dwarf_d0;
 if (i < 16)
-m_vfp_regs.sd_regs[idx].d_reg = reg_value.GetAsUInt64();
+{
+m_vfp_regs.s_regs[idx * 2] = (uint32_t)value;
+m_vfp_regs.s_regs[idx * 2 + 1] = (uint32_t)(value >> 32);
+}
 else
-m_vfp_regs.d_regs[idx - 16] = reg_value.GetAsUInt64();
+m_vfp_regs.d_regs[idx - 16] = value;
 }
 else
 success = false;
@@ -82,16 +86,18 @@ EmulationStateARM::StorePseudoRegisterVa
 else if ((dwarf_s0 <= reg_num) && (reg_num <= dwarf_s31))
 {
 uint32_t idx = reg_num - dwarf_s0;
-m_vfp_regs.sd_regs[idx / 2].s_reg[idx % 2] = (uint32_t) value;
+m_vfp_regs.s_regs[idx] = (uint32_t)value;
 }
 else if ((dwarf_d0 <= reg_num) && (reg_num <= dwarf_d31))
 {
-if ((reg_num - dwarf_d0) < 16)
+uint32_t idx = reg_num - dwarf_d0;
+if (idx < 16)
 {
-m_vfp_regs.sd_regs[reg_num - dwarf_d0].d_reg = value;
+m_vfp_regs.s_regs[idx * 2] = (uint32_t)value;
+m_vfp_regs.s_regs[idx * 2 + 1] = (uint32_t)(value >> 32);
 }
 else
-m_vfp_regs.d_regs[reg_num - dwarf_d16] = value;
+m_vfp_regs.d_regs[idx - 16] = value;
 }
 else
 return false;
@@ -110,14 +116,15 @@ EmulationStateARM::ReadPseudoRegisterVal
 else if ((dwarf_s0 <= reg_num) && (reg_n

Re: [Lldb-commits] [PATCH] D18983: Miscellaneous fixes for big-endian systems

[Ulrich Weigand via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL266313: Miscellaneous fixes for big-endian systems (authored 
by uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18983?vs=53299&id=53712#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18983

Files:
  lldb/trunk/examples/synthetic/gnu_libstdcpp.py
  lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
  lldb/trunk/source/Symbol/ClangASTContext.cpp
  lldb/trunk/source/Target/Process.cpp

Index: lldb/trunk/examples/synthetic/gnu_libstdcpp.py
===
--- lldb/trunk/examples/synthetic/gnu_libstdcpp.py
+++ lldb/trunk/examples/synthetic/gnu_libstdcpp.py
@@ -237,11 +237,12 @@
def get_child_at_index(self, index):
if index >= self.num_children():
return None
-   byte_offset = index / 8
-   bit_offset = index % 8
-   element_size = 
self.start_p.GetType().GetPointeeType().GetByteSize()
-   data = self.start_p.GetPointeeData(byte_offset / 
element_size)
-   bit = data.GetUnsignedInt8(lldb.SBError(), byte_offset 
% element_size) & (1 << bit_offset)
+   element_type = self.start_p.GetType().GetPointeeType()
+   element_bits = 8 * element_type.GetByteSize()
+   element_offset = index / element_bits
+   bit_offset = index % element_bits
+   element = 
self.start_p.CreateChildAtOffset('['+str(index)+']',element_offset,element_type)
+   bit = element.GetValueAsUnsigned(0) & (1 << bit_offset)
if bit != 0:
value_expr = "(bool)true"
else:
Index: lldb/trunk/source/Target/Process.cpp
===
--- lldb/trunk/source/Target/Process.cpp
+++ lldb/trunk/source/Target/Process.cpp
@@ -2437,7 +2437,7 @@
 // Search for a null terminator of correct size and alignment in 
bytes_read
 size_t aligned_start = total_bytes_read - total_bytes_read % 
type_width;
 for (size_t i = aligned_start; i + type_width <= total_bytes_read 
+ bytes_read; i += type_width)
-if (::strncmp(&dst[i], terminator, type_width) == 0)
+if (::memcmp(&dst[i], terminator, type_width) == 0)
 {
 error.Clear();
 return i;
Index: lldb/trunk/source/Symbol/ClangASTContext.cpp
===
--- lldb/trunk/source/Symbol/ClangASTContext.cpp
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp
@@ -6075,8 +6075,9 @@
 {
 clang::CharUnits 
base_offset_offset = 
itanium_vtable_ctx->getVirtualBaseOffsetOffset(cxx_record_decl, 
base_class_decl);
 const lldb::addr_t 
base_offset_addr = vtable_ptr + base_offset_offset.getQuantity();
-const uint32_t 
base_offset = process->ReadUnsignedIntegerFromMemory(base_offset_addr, 4, 
UINT32_MAX, err);
-if (base_offset != 
UINT32_MAX)
+const uint32_t 
base_offset_size = process->GetAddressByteSize();
+const uint64_t 
base_offset = process->ReadUnsignedIntegerFromMemory(base_offset_addr, 
base_offset_size, UINT32_MAX, err);
+if (base_offset < 
UINT32_MAX)
 {
 handled = true;
 bit_offset = 
base_offset * 8;
Index: lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
===
--- lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
@@ -192,13 +192,33 @@
 if (error.Fail())
 return false;
 
+// Get a wchar_t basic type from the current type system
+CompilerType wchar_compiler_type = 
valobj.GetCompilerType().GetBasicTypeFromAST(lldb::eBasicTypeWChar);
+
+if (!wchar_compiler_type)
+return false;
+
+const uint32_t wchar_size = wchar_compiler_type.GetBitSize(nullptr); // 
Safe to pass NULL for exe_scope here
+
 StringPrinter::ReadBufferAndDumpToStreamOptions options(valobj);
 options.SetData(data);
 options.SetStream(&stream);
 opt

[Lldb-commits] [lldb] r266313 - Miscellaneous fixes for big-endian systems

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Thu Apr 14 09:33:47 2016
New Revision: 266313

URL: http://llvm.org/viewvc/llvm-project?rev=266313&view=rev
Log:
Miscellaneous fixes for big-endian systems

This patch fixes a bunch of issues that show up on big-endian systems:

- The gnu_libstdcpp.py script doesn't follow the way libstdc++ encodes
  bit vectors: it should identify the enclosing *word* and then access
  the appropriate bit within that word.  Instead, the script simply
  operates on bytes.  This gives the same result on little-endian
  systems, but not on big-endian.

- lldb_private::formatters::WCharSummaryProvider always assumes wchar_t
  is UTF16, even though it could also be UTF8 or UTF32.  This is mostly
  not an issue on little-endian systems, but immediately fails on BE.
  Fixed by checking the size of wchar_t like WCharStringSummaryProvider
  already does.

- ClangASTContext::GetChildCompilerTypeAtIndex uses uint32_t to access
  the virtual base offset stored in the vtable, even though the size
  of this field matches the target pointer size according to the C++
  ABI.  Again, this is mostly not visible on LE, but fails on BE.

- Process::ReadStringFromMemory uses strncmp to search for a terminator
  consisting of multiple zero bytes.  This doesn't work since strncmp
  will stop already at the first zero byte.  Use memcmp instead.

Differential Revision: http://reviews.llvm.org/D18983


Modified:
lldb/trunk/examples/synthetic/gnu_libstdcpp.py
lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
lldb/trunk/source/Symbol/ClangASTContext.cpp
lldb/trunk/source/Target/Process.cpp

Modified: lldb/trunk/examples/synthetic/gnu_libstdcpp.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/examples/synthetic/gnu_libstdcpp.py?rev=266313&r1=266312&r2=266313&view=diff
==
--- lldb/trunk/examples/synthetic/gnu_libstdcpp.py (original)
+++ lldb/trunk/examples/synthetic/gnu_libstdcpp.py Thu Apr 14 09:33:47 2016
@@ -237,11 +237,12 @@ class StdVectorSynthProvider:
def get_child_at_index(self, index):
if index >= self.num_children():
return None
-   byte_offset = index / 8
-   bit_offset = index % 8
-   element_size = 
self.start_p.GetType().GetPointeeType().GetByteSize()
-   data = self.start_p.GetPointeeData(byte_offset / 
element_size)
-   bit = data.GetUnsignedInt8(lldb.SBError(), byte_offset 
% element_size) & (1 << bit_offset)
+   element_type = self.start_p.GetType().GetPointeeType()
+   element_bits = 8 * element_type.GetByteSize()
+   element_offset = index / element_bits
+   bit_offset = index % element_bits
+   element = 
self.start_p.CreateChildAtOffset('['+str(index)+']',element_offset,element_type)
+   bit = element.GetValueAsUnsigned(0) & (1 << bit_offset)
if bit != 0:
value_expr = "(bool)true"
else:

Modified: lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp?rev=266313&r1=266312&r2=266313&view=diff
==
--- lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp (original)
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp Thu Apr 14 
09:33:47 2016
@@ -192,6 +192,14 @@ lldb_private::formatters::WCharSummaryPr
 if (error.Fail())
 return false;
 
+// Get a wchar_t basic type from the current type system
+CompilerType wchar_compiler_type = 
valobj.GetCompilerType().GetBasicTypeFromAST(lldb::eBasicTypeWChar);
+
+if (!wchar_compiler_type)
+return false;
+
+const uint32_t wchar_size = wchar_compiler_type.GetBitSize(nullptr); // 
Safe to pass NULL for exe_scope here
+
 StringPrinter::ReadBufferAndDumpToStreamOptions options(valobj);
 options.SetData(data);
 options.SetStream(&stream);
@@ -200,5 +208,17 @@ lldb_private::formatters::WCharSummaryPr
 options.SetSourceSize(1);
 options.SetBinaryZeroIsTerminator(false);
 
-return 
StringPrinter::ReadBufferAndDumpToStream(options);
+switch (wchar_size)
+{
+case 8:
+return 
StringPrinter::ReadBufferAndDumpToStream(options);
+case 16:
+return 
StringPrinter::ReadBufferAndDumpToStream(options);
+case 32:
+return 
StringPrinter::ReadBufferAndDumpToStream(options);
+default:
+stream.Printf("size for wchar_t is not valid");
+return true;
+}
+return true;
 }

Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp
URL: 
http://l

Re: [Lldb-commits] [PATCH] D18982: Handle bit fields on big-endian systems correctly

[Ulrich Weigand via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL266312: Handle bit fields on big-endian systems correctly 
(authored by uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18982?vs=53605&id=53711#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18982

Files:
  lldb/trunk/include/lldb/Core/DataExtractor.h
  lldb/trunk/source/Core/DataExtractor.cpp
  lldb/trunk/source/Core/ValueObject.cpp
  lldb/trunk/unittests/Core/CMakeLists.txt
  lldb/trunk/unittests/Core/DataExtractorTest.cpp

Index: lldb/trunk/include/lldb/Core/DataExtractor.h
===
--- lldb/trunk/include/lldb/Core/DataExtractor.h
+++ lldb/trunk/include/lldb/Core/DataExtractor.h
@@ -763,8 +763,10 @@
 ///
 /// @param[in] bitfield_bit_offset
 /// The bit offset of the bitfield value in the extracted
-/// integer (the number of bits to shift the integer to the
-/// right).
+/// integer.  For little-endian data, this is the offset of
+/// the LSB of the bitfield from the LSB of the integer.
+/// For big-endian data, this is the offset of the MSB of the
+/// bitfield from the MSB of the integer.
 ///
 /// @return
 /// The unsigned bitfield integer value that was extracted, or
@@ -805,8 +807,10 @@
 ///
 /// @param[in] bitfield_bit_offset
 /// The bit offset of the bitfield value in the extracted
-/// integer (the number of bits to shift the integer to the
-/// right).
+/// integer.  For little-endian data, this is the offset of
+/// the LSB of the bitfield from the LSB of the integer.
+/// For big-endian data, this is the offset of the MSB of the
+/// bitfield from the MSB of the integer.
 ///
 /// @return
 /// The signed bitfield integer value that was extracted, or
Index: lldb/trunk/unittests/Core/DataExtractorTest.cpp
===
--- lldb/trunk/unittests/Core/DataExtractorTest.cpp
+++ lldb/trunk/unittests/Core/DataExtractorTest.cpp
@@ -0,0 +1,39 @@
+//===-- DataExtractorTest.cpp ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#if defined(_MSC_VER) && (_HAS_EXCEPTIONS == 0)
+// Workaround for MSVC standard library bug, which fails to include  when
+// exceptions are disabled.
+#include 
+#endif
+
+#include "gtest/gtest.h"
+
+#include "lldb/Core/DataExtractor.h"
+
+using namespace lldb_private;
+
+TEST(DataExtractorTest, GetBitfield)
+{
+char buffer[] = { 0x01, 0x23, 0x45, 0x67 };
+DataExtractor LE(buffer, sizeof(buffer), lldb::eByteOrderLittle, sizeof(void *));
+DataExtractor BE(buffer, sizeof(buffer), lldb::eByteOrderBig, sizeof(void *));
+
+lldb::offset_t offset;
+
+offset = 0;
+ASSERT_EQ(buffer[1], LE.GetMaxU64Bitfield(&offset, sizeof(buffer), 8, 8));
+offset = 0;
+ASSERT_EQ(buffer[1], BE.GetMaxU64Bitfield(&offset, sizeof(buffer), 8, 8));
+
+offset = 0;
+ASSERT_EQ(buffer[1], LE.GetMaxS64Bitfield(&offset, sizeof(buffer), 8, 8));
+offset = 0;
+ASSERT_EQ(buffer[1], BE.GetMaxS64Bitfield(&offset, sizeof(buffer), 8, 8));
+}
Index: lldb/trunk/unittests/Core/CMakeLists.txt
===
--- lldb/trunk/unittests/Core/CMakeLists.txt
+++ lldb/trunk/unittests/Core/CMakeLists.txt
@@ -1,3 +1,4 @@
 add_lldb_unittest(LLDBCoreTests
+  DataExtractorTest.cpp
   ScalarTest.cpp
   )
Index: lldb/trunk/source/Core/ValueObject.cpp
===
--- lldb/trunk/source/Core/ValueObject.cpp
+++ lldb/trunk/source/Core/ValueObject.cpp
@@ -2146,15 +2146,19 @@
 synthetic_child_sp = GetSyntheticChild (index_const_str);
 if (!synthetic_child_sp)
 {
+uint32_t bit_field_size = to - from + 1;
+uint32_t bit_field_offset = from;
+if (GetDataExtractor().GetByteOrder() == eByteOrderBig)
+bit_field_offset = GetByteSize() * 8 - bit_field_size - bit_field_offset;
 // We haven't made a synthetic array member for INDEX yet, so
 // lets make one and cache it for any future reference.
 ValueObjectChild *synthetic_child = new ValueObjectChild (*this,
   GetCompilerType(),
   index_const_str,
   GetByteSize(),
   0,
- 

[Lldb-commits] [lldb] r266312 - Handle bit fields on big-endian systems correctly

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Thu Apr 14 09:32:57 2016
New Revision: 266312

URL: http://llvm.org/viewvc/llvm-project?rev=266312&view=rev
Log:
Handle bit fields on big-endian systems correctly

Currently, the DataExtractor::GetMaxU64Bitfield and GetMaxS64Bitfield
routines assume the incoming "bitfield_bit_offset" parameter uses
little-endian bit numbering, i.e. a bitfield_bit_offset 0 refers to
a bitfield whose least-significant bit coincides with the least-
significant bit of the surrounding integer.

On many big-endian systems, however, the big-endian bit numbering
is used for bit fields.  Here, a bitfield_bit_offset 0 refers to
a bitfield whose most-significant bit conincides with the most-
significant bit of the surrounding integer.

Now, in principle LLDB could arbitrarily choose which semantics of
bitfield_bit_offset to use.  However, there are two problems with
the current approach:

- When parsing DWARF, LLDB decodes bit offsets in little-endian
  bit numbering on LE systems, but in big-endian bit numbering
  on BE systems.  Passing those offsets later on into the
  DataExtractor routines gives incorrect results on BE.

- In the interim, LLDB's type layer combines byte and bit offsets
  into a single number.  I.e. instead of recording bitfields by
  specifying the byte offset and byte size of the surrounding
  integer *plus* the bit offset of the bit field within that field,
  it simply records a single bit offset number.

  Now, note that converting from byte offset + bit offset to a
  single offset value and back is well-defined if we either use
  little-endian byte order *and* little-endian bit numbering,
  or use big-endian byte order *and* big-endian bit numbering.
  Any other combination will yield incorrect results.

Therefore, the simplest approach would seem to be to always use
the bit numbering that matches the system byte order.  This makes
storing a single bit offset valid, and makes the existing DWARF
code correct.  The only place to fix is to teach DataExtractor
to use big-endian bit numbering on big endian systems.

However, there is only additional caveat: we also get bit offsets
from LLDB synthetic bitfields.  While the exact semantics of those
doesn't seem to be well-defined, from test cases it appears that
the intent was for the user-provided synthetic bitfield offset to
always use little-endian bit numbering.  Therefore, on a big-endian
system we now have to convert those to big-endian bit numbering
to remain consistent.

Differential Revision: http://reviews.llvm.org/D18982


Added:
lldb/trunk/unittests/Core/DataExtractorTest.cpp
Modified:
lldb/trunk/include/lldb/Core/DataExtractor.h
lldb/trunk/source/Core/DataExtractor.cpp
lldb/trunk/source/Core/ValueObject.cpp
lldb/trunk/unittests/Core/CMakeLists.txt

Modified: lldb/trunk/include/lldb/Core/DataExtractor.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/DataExtractor.h?rev=266312&r1=266311&r2=266312&view=diff
==
--- lldb/trunk/include/lldb/Core/DataExtractor.h (original)
+++ lldb/trunk/include/lldb/Core/DataExtractor.h Thu Apr 14 09:32:57 2016
@@ -763,8 +763,10 @@ public:
 ///
 /// @param[in] bitfield_bit_offset
 /// The bit offset of the bitfield value in the extracted
-/// integer (the number of bits to shift the integer to the
-/// right).
+/// integer.  For little-endian data, this is the offset of
+/// the LSB of the bitfield from the LSB of the integer.
+/// For big-endian data, this is the offset of the MSB of the
+/// bitfield from the MSB of the integer.
 ///
 /// @return
 /// The unsigned bitfield integer value that was extracted, or
@@ -805,8 +807,10 @@ public:
 ///
 /// @param[in] bitfield_bit_offset
 /// The bit offset of the bitfield value in the extracted
-/// integer (the number of bits to shift the integer to the
-/// right).
+/// integer.  For little-endian data, this is the offset of
+/// the LSB of the bitfield from the LSB of the integer.
+/// For big-endian data, this is the offset of the MSB of the
+/// bitfield from the MSB of the integer.
 ///
 /// @return
 /// The signed bitfield integer value that was extracted, or

Modified: lldb/trunk/source/Core/DataExtractor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/DataExtractor.cpp?rev=266312&r1=266311&r2=266312&view=diff
==
--- lldb/trunk/source/Core/DataExtractor.cpp (original)
+++ lldb/trunk/source/Core/DataExtractor.cpp Thu Apr 14 09:32:57 2016
@@ -733,8 +733,11 @@ DataExtractor::GetMaxU64Bitfield (offset
 uint64_t uval64 = GetMaxU64 (offset_ptr, size);
 if (bitfield_bit_size > 0)
 {
-if (bitfield_bit_offset > 0)
-uval64 >>= bitfield_bit_offset;
+int

Re: [Lldb-commits] [PATCH] D18979: Fixes for platforms that default to unsigned char

[Ulrich Weigand via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL266309: Fixes for platforms that default to unsigned char 
(authored by uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18979?vs=53294&id=53708#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18979

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
  lldb/trunk/source/Symbol/ClangASTContext.cpp

Index: 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
===
--- 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
+++ 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
@@ -57,7 +57,7 @@
 def test_default_char(self):
 self.do_test()
 
-@expectedFailureAll(archs=["arm", "aarch64"], bugnumber="llvm.org/pr23069")
+@expectedFailureAll(archs=["arm", "aarch64", "s390x"], 
bugnumber="llvm.org/pr23069")
 @expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr21765")
 def test_signed_char(self):
 self.do_test(dictionary={'CFLAGS_EXTRAS': '-fsigned-char'})
Index: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
===
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
@@ -6,7 +6,7 @@
 // License. See LICENSE.TXT for details.
 //
 
//===--===//
-typedef char v4i8 __attribute__ ((vector_size(4)));
+typedef signed char v4i8 __attribute__ ((vector_size(4)));
 v4i8 global_vector = {1, 2, 3, 4};
 
 int
Index: lldb/trunk/source/Symbol/ClangASTContext.cpp
===
--- lldb/trunk/source/Symbol/ClangASTContext.cpp
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp
@@ -783,8 +783,8 @@
 break;
 
 case eEncodingSint:
-if (QualTypeMatchesBitSize (bit_size, ast, ast->CharTy))
-return CompilerType (ast, ast->CharTy);
+if (QualTypeMatchesBitSize (bit_size, ast, ast->SignedCharTy))
+return CompilerType (ast, ast->SignedCharTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->ShortTy))
 return CompilerType (ast, ast->ShortTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->IntTy))


Index: lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
+++ lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
@@ -57,7 +57,7 @@
 def test_default_char(self):
 self.do_test()
 
-@expectedFailureAll(archs=["arm", "aarch64"], bugnumber="llvm.org/pr23069")
+@expectedFailureAll(archs=["arm", "aarch64", "s390x"], bugnumber="llvm.org/pr23069")
 @expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr21765")
 def test_signed_char(self):
 self.do_test(dictionary={'CFLAGS_EXTRAS': '-fsigned-char'})
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
@@ -6,7 +6,7 @@
 // License. See LICENSE.TXT for details.
 //
 //===--===//
-typedef char v4i8 __attribute__ ((vector_size(4)));
+typedef signed char v4i8 __attribute__ ((vector_size(4)));
 v4i8 global_vector = {1, 2, 3, 4};
 
 int
Index: lldb/trunk/source/Symbol/ClangASTContext.cpp
===
--- lldb/trunk/source/Symbol/ClangASTContext.cpp
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp
@@ -783,8 +783,8 @@
 break;
 
 case eEncodingSint:
-if (QualTypeMatchesBitSize (bit_size, ast, ast->CharTy))
-return CompilerType (ast, ast->CharTy);
+if (QualTypeMatchesBitSize (bit_size, ast, ast->SignedCharTy))
+return CompilerType (ast, ast->SignedCharTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->ShortTy))
 return CompilerType (ast, ast->ShortTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->IntTy))
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists

[Lldb-commits] [lldb] r266310 - Make Scalar::GetBytes and RegisterValue::GetBytes const

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Thu Apr 14 09:31:08 2016
New Revision: 266310

URL: http://llvm.org/viewvc/llvm-project?rev=266310&view=rev
Log:
Make Scalar::GetBytes and RegisterValue::GetBytes const

Scalar::GetBytes provides a non-const access to the underlying bytes
of the scalar value, supposedly allowing for modification of those
bytes.  However, even with the current implementation, this is not
really possible.  For floating-point scalars, the pointer returned
by GetBytes refers to a temporary copy; modifications to that copy
will be simply ignored.  For integer scalars, the pointer refers
to internal memory of the APInt implementation, which isn't
supposed to be directly modifyable; GetBytes simply casts aways
the const-ness of the pointer ...

With my upcoming patch to fix Scalar::GetBytes for big-endian
systems, this problem is going to get worse, since there we need
temporary copies even for some integer scalars.  Therefore, this
patch makes Scalar::GetBytes const, fixing all those problems.

As a follow-on change, RegisterValues::GetBytes must be made const
as well.  This in turn means that the way of initializing a
RegisterValue by doing a SetType followed by writing to GetBytes
no longer works.  Instead, I've changed SetValueFromData to do
the equivalent of SetType itself, and then re-implemented
SetFromMemoryData to work on top of SetValueFromData. 

There is still a need for RegisterValue::SetType, since some
platform-specific code uses it to reinterpret the contents of
an already filled RegisterValue.  To make this usage work in
all cases (even changing from a type implemented via Scalar
to a type implemented as a byte buffer), SetType now simply
copies the old contents out, and then reloads the RegisterValue
from this data using the new type via SetValueFromData.

This in turn means that there is no remaining caller of
Scalar::SetType, so it can be removed.

The only other follow-on change was in MIPS EmulateInstruction
code, where some uses of RegisterValue::GetBytes could be made
const trivially.

Differential Revision: http://reviews.llvm.org/D18980


Modified:
lldb/trunk/include/lldb/Core/RegisterValue.h
lldb/trunk/include/lldb/Core/Scalar.h
lldb/trunk/source/Core/RegisterValue.cpp
lldb/trunk/source/Core/Scalar.cpp
lldb/trunk/source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
lldb/trunk/source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp

Modified: lldb/trunk/include/lldb/Core/RegisterValue.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/RegisterValue.h?rev=266310&r1=266309&r2=266310&view=diff
==
--- lldb/trunk/include/lldb/Core/RegisterValue.h (original)
+++ lldb/trunk/include/lldb/Core/RegisterValue.h Thu Apr 14 09:31:08 2016
@@ -354,9 +354,6 @@ namespace lldb_private {
   lldb::Format format,
   uint32_t reg_name_right_align_at = 0) const;
 
-void *
-GetBytes ();
-
 const void *
 GetBytes () const;
 

Modified: lldb/trunk/include/lldb/Core/Scalar.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Scalar.h?rev=266310&r1=266309&r2=266310&view=diff
==
--- lldb/trunk/include/lldb/Core/Scalar.h (original)
+++ lldb/trunk/include/lldb/Core/Scalar.h Thu Apr 14 09:31:08 2016
@@ -120,7 +120,7 @@ public:
 bool
 ClearBit(uint32_t bit);
 
-void *
+const void *
 GetBytes() const;
 
 size_t
@@ -231,9 +231,6 @@ public:
 Scalar::Type
 GetType() const { return m_type; }
 
-void
-SetType(const RegisterInfo*);
-
 //--
 // Returns a casted value of the current contained data without
 // modifying the current value. FAIL_VALUE will be returned if the type

Modified: lldb/trunk/source/Core/RegisterValue.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/RegisterValue.cpp?rev=266310&r1=266309&r2=266310&view=diff
==
--- lldb/trunk/source/Core/RegisterValue.cpp (original)
+++ lldb/trunk/source/Core/RegisterValue.cpp Thu Apr 14 09:31:08 2016
@@ -203,34 +203,13 @@ RegisterValue::SetFromMemoryData (const
 // Use a data extractor to correctly copy and pad the bytes read into the
 // register value
 DataExtractor src_data (src, src_len, src_byte_order, 4);
-
-// Given the register info, set the value type of this RegisterValue object
-SetType (reg_info);
-// And make sure we were able to figure out what that register value was
-RegisterValue::Type value_type = GetType();
-if (value_type == eTypeInvalid)
-{
-// No value has been read into this object...
-error.SetErrorStringWithFormat("invalid register value type for 
register %s", reg_info->name);

[Lldb-commits] [lldb] r266309 - Fixes for platforms that default to unsigned char

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Thu Apr 14 09:30:12 2016
New Revision: 266309

URL: http://llvm.org/viewvc/llvm-project?rev=266309&view=rev
Log:
Fixes for platforms that default to unsigned char

This fixes several test case failure on s390x caused by the fact that
on this platform, the default "char" type is unsigned.

- In ClangASTContext::GetBuiltinTypeForEncodingAndBitSize we should return
  an explicit *signed* char type for encoding eEncodingSint and bit size 8,
  instead of the default platform char type (which may be unsigned).
  This fix matches existing code in ClangASTContext::GetIntTypeFromBitSize,
  and fixes the TestClangASTContext.TestBuiltinTypeForEncodingAndBitSize
  unit test case.

- The test/expression_command/char/TestExprsChar.py test case is known to
  fail on platforms defaulting to unsigned char (pr23069), and just needs
  to be xfailed on s390x like on arm.

- The test/functionalities/watchpoint/watchpoint_on_vectors/main.c test
  case defines a vector of "char" and implicitly assumes to be signed.
  Use an explicit "signed char" instead.

Differential Revision: http://reviews.llvm.org/D18979


Modified:

lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
lldb/trunk/source/Symbol/ClangASTContext.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py?rev=266309&r1=266308&r2=266309&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
 Thu Apr 14 09:30:12 2016
@@ -57,7 +57,7 @@ class ExprCharTestCase(TestBase):
 def test_default_char(self):
 self.do_test()
 
-@expectedFailureAll(archs=["arm", "aarch64"], bugnumber="llvm.org/pr23069")
+@expectedFailureAll(archs=["arm", "aarch64", "s390x"], 
bugnumber="llvm.org/pr23069")
 @expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr21765")
 def test_signed_char(self):
 self.do_test(dictionary={'CFLAGS_EXTRAS': '-fsigned-char'})

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c?rev=266309&r1=266308&r2=266309&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
 Thu Apr 14 09:30:12 2016
@@ -6,7 +6,7 @@
 // License. See LICENSE.TXT for details.
 //
 
//===--===//
-typedef char v4i8 __attribute__ ((vector_size(4)));
+typedef signed char v4i8 __attribute__ ((vector_size(4)));
 v4i8 global_vector = {1, 2, 3, 4};
 
 int

Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ClangASTContext.cpp?rev=266309&r1=266308&r2=266309&view=diff
==
--- lldb/trunk/source/Symbol/ClangASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp Thu Apr 14 09:30:12 2016
@@ -783,8 +783,8 @@ ClangASTContext::GetBuiltinTypeForEncodi
 break;
 
 case eEncodingSint:
-if (QualTypeMatchesBitSize (bit_size, ast, ast->CharTy))
-return CompilerType (ast, ast->CharTy);
+if (QualTypeMatchesBitSize (bit_size, ast, ast->SignedCharTy))
+return CompilerType (ast, ast->SignedCharTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->ShortTy))
 return CompilerType (ast, ast->ShortTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->IntTy))


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

Re: [Lldb-commits] [PATCH] D18977: Add new ABI callback to provide fallback unwind register locations

[Ulrich Weigand via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL266307: Add new ABI callback to provide fallback unwind 
register locations (authored by uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18977?vs=53502&id=53706#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18977

Files:
  lldb/trunk/include/lldb/Symbol/UnwindPlan.h
  lldb/trunk/include/lldb/Target/ABI.h
  lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
  lldb/trunk/source/Target/ABI.cpp

Index: lldb/trunk/include/lldb/Target/ABI.h
===
--- lldb/trunk/include/lldb/Target/ABI.h
+++ lldb/trunk/include/lldb/Target/ABI.h
@@ -16,6 +16,7 @@
 // Project includes
 #include "lldb/Core/Error.h"
 #include "lldb/Core/PluginInterface.h"
+#include "lldb/Symbol/UnwindPlan.h"
 #include "lldb/lldb-private.h"
 
 #include "llvm/ADT/ArrayRef.h"
@@ -110,6 +111,10 @@
 virtual bool
 RegisterIsVolatile (const RegisterInfo *reg_info) = 0;
 
+virtual bool
+GetFallbackRegisterLocation (const RegisterInfo *reg_info,
+ UnwindPlan::Row::RegisterLocation &unwind_regloc);
+
 // Should take a look at a call frame address (CFA) which is just the stack
 // pointer value upon entry to a function. ABIs usually impose alignment
 // restrictions (4, 8 or 16 byte aligned), and zero is usually not allowed.
Index: lldb/trunk/include/lldb/Symbol/UnwindPlan.h
===
--- lldb/trunk/include/lldb/Symbol/UnwindPlan.h
+++ lldb/trunk/include/lldb/Symbol/UnwindPlan.h
@@ -116,6 +116,12 @@
 return m_type == unspecified; 
 }
 
+bool
+IsUndefined () const
+{
+return m_type == undefined;
+}
+
 bool 
 IsCFAPlusOffset () const
 {
Index: lldb/trunk/source/Target/ABI.cpp
===
--- lldb/trunk/source/Target/ABI.cpp
+++ lldb/trunk/source/Target/ABI.cpp
@@ -205,3 +205,27 @@
 assert( !"Should never get here!" );
 return false;
 }
+
+bool
+ABI::GetFallbackRegisterLocation (const RegisterInfo *reg_info,
+  UnwindPlan::Row::RegisterLocation &unwind_regloc)
+{
+// Did the UnwindPlan fail to give us the caller's stack pointer?
+// The stack pointer is defined to be the same as THIS frame's CFA, so return the CFA value as
+// the caller's stack pointer.  This is true on x86-32/x86-64 at least.
+if (reg_info->kinds[eRegisterKindGeneric] == LLDB_REGNUM_GENERIC_SP)
+{
+unwind_regloc.SetIsCFAPlusOffset(0);
+return true;
+}
+
+// If a volatile register is being requested, we don't want to forward the next frame's register contents
+// up the stack -- the register is not retrievable at this frame.
+if (RegisterIsVolatile(reg_info))
+{
+unwind_regloc.SetUndefined();
+return true;
+}
+
+return false;
+}
Index: lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
===
--- lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
+++ lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
@@ -1390,45 +1390,28 @@
 }
 }
 
-if (have_unwindplan_regloc == false)
-{
-// Did the UnwindPlan fail to give us the caller's stack pointer?  
-// The stack pointer is defined to be the same as THIS frame's CFA, so return the CFA value as
-// the caller's stack pointer.  This is true on x86-32/x86-64 at least.
-
-RegisterNumber sp_regnum (m_thread, eRegisterKindGeneric, LLDB_REGNUM_GENERIC_SP);
-if (sp_regnum.GetAsKind (eRegisterKindLLDB) != LLDB_INVALID_REGNUM 
-&& sp_regnum.GetAsKind (eRegisterKindLLDB) == regnum.GetAsKind (eRegisterKindLLDB))
-{
-// make sure we won't lose precision copying an addr_t (m_cfa) into a uint64_t (.inferred_value)
-assert (sizeof (addr_t) <= sizeof (uint64_t));
-regloc.type = UnwindLLDB::RegisterLocation::eRegisterValueInferred;
-regloc.location.inferred_value = m_cfa;
-m_registers[regnum.GetAsKind (eRegisterKindLLDB)] = regloc;
-UnwindLogMsg ("supplying caller's stack pointer %s (%d) value, computed from CFA", 
-regnum.GetName(), regnum.GetAsKind (eRegisterKindLLDB));
-return UnwindLLDB::RegisterSearchResult::eRegisterFound;
-}
-}
-
 ExecutionContext exe_ctx(m_thread.shared_from_this());
 Process *process = exe_ctx.GetProcessPtr();
 if (have_unwindplan_regloc == false)
 {
-// If a volatile register is being requested, we don't want to forward the next frame's register contents
-// up the stack -- the register is not retrievable at this

[Lldb-commits] [lldb] r266307 - Add new ABI callback to provide fallback unwind register locations

[Ulrich Weigand via lldb-commits]

Author: uweigand
Date: Thu Apr 14 09:25:20 2016
New Revision: 266307

URL: http://llvm.org/viewvc/llvm-project?rev=266307&view=rev
Log:
Add new ABI callback to provide fallback unwind register locations

If the UnwindPlan did not identify how to unwind the stack pointer
register, LLDB currently assumes it can determine to caller's SP
from the current frame's CFA.  This is true on most platforms
where CFA is by definition equal to the incoming SP at function
entry.

However, on the s390x target, we instead define the CFA to equal
the incoming SP plus an offset of 160 bytes.  This is because
our ABI defines that the caller has to provide a register save
area of size 160 bytes.  This area is allocated by the caller,
but is considered part of the callee's stack frame, and therefore
the CFA is defined as pointing to the top of this area.

In order to make this work on s390x, this patch introduces a new
ABI callback GetFallbackRegisterLocation that provides platform-
specific fallback register locations for unwinding.  The existing
code to handle SP unwinding as well as volatile registers is moved
into the default implementation of that ABI callback, to allow
targets where that implementation is incorrect to override it.

This patch in itself is a no-op for all existing platforms.
But it is a pre-requisite for adding s390x support.

Differential Revision: http://reviews.llvm.org/D18977


Modified:
lldb/trunk/include/lldb/Symbol/UnwindPlan.h
lldb/trunk/include/lldb/Target/ABI.h
lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
lldb/trunk/source/Target/ABI.cpp

Modified: lldb/trunk/include/lldb/Symbol/UnwindPlan.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/UnwindPlan.h?rev=266307&r1=266306&r2=266307&view=diff
==
--- lldb/trunk/include/lldb/Symbol/UnwindPlan.h (original)
+++ lldb/trunk/include/lldb/Symbol/UnwindPlan.h Thu Apr 14 09:25:20 2016
@@ -116,6 +116,12 @@ public:
 return m_type == unspecified; 
 }
 
+bool
+IsUndefined () const
+{
+return m_type == undefined;
+}
+
 bool 
 IsCFAPlusOffset () const
 {

Modified: lldb/trunk/include/lldb/Target/ABI.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/ABI.h?rev=266307&r1=266306&r2=266307&view=diff
==
--- lldb/trunk/include/lldb/Target/ABI.h (original)
+++ lldb/trunk/include/lldb/Target/ABI.h Thu Apr 14 09:25:20 2016
@@ -16,6 +16,7 @@
 // Project includes
 #include "lldb/Core/Error.h"
 #include "lldb/Core/PluginInterface.h"
+#include "lldb/Symbol/UnwindPlan.h"
 #include "lldb/lldb-private.h"
 
 #include "llvm/ADT/ArrayRef.h"
@@ -110,6 +111,10 @@ public:
 virtual bool
 RegisterIsVolatile (const RegisterInfo *reg_info) = 0;
 
+virtual bool
+GetFallbackRegisterLocation (const RegisterInfo *reg_info,
+ UnwindPlan::Row::RegisterLocation 
&unwind_regloc);
+
 // Should take a look at a call frame address (CFA) which is just the stack
 // pointer value upon entry to a function. ABIs usually impose alignment
 // restrictions (4, 8 or 16 byte aligned), and zero is usually not allowed.

Modified: lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp?rev=266307&r1=266306&r2=266307&view=diff
==
--- lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp (original)
+++ lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp Thu Apr 
14 09:25:20 2016
@@ -1390,45 +1390,28 @@ RegisterContextLLDB::SavedLocationForReg
 }
 }
 
-if (have_unwindplan_regloc == false)
-{
-// Did the UnwindPlan fail to give us the caller's stack pointer?  
-// The stack pointer is defined to be the same as THIS frame's CFA, so 
return the CFA value as
-// the caller's stack pointer.  This is true on x86-32/x86-64 at least.
-
-RegisterNumber sp_regnum (m_thread, eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_SP);
-if (sp_regnum.GetAsKind (eRegisterKindLLDB) != LLDB_INVALID_REGNUM 
-&& sp_regnum.GetAsKind (eRegisterKindLLDB) == regnum.GetAsKind 
(eRegisterKindLLDB))
-{
-// make sure we won't lose precision copying an addr_t (m_cfa) 
into a uint64_t (.inferred_value)
-assert (sizeof (addr_t) <= sizeof (uint64_t));
-regloc.type = UnwindLLDB::RegisterLocation::eRegisterValueInferred;
-regloc.location.inferred_value = m_cfa;
-m_registers[regnum.GetAsKind (eRegisterKindLLDB)] = regloc;
-UnwindLogMsg ("supplying caller's stack pointer %s (%

Re: [Lldb-commits] [PATCH] D18981: Fix usage of APInt.getRawData for big-endian systems

[Ulrich Weigand via lldb-commits]

uweigand updated this revision to Diff 53622.
uweigand added a comment.

This adds some unit tests verifying correct operation of the GetBytes routine 
as well as the conversions (SChar, UChar, ...).  Those tests actually exposed 
more problems in the original Scalar code: the SetValueFromData routine didn't 
work correctly for 128- and 256-bit data types, and the SChar routine should 
have an explicit "signed char" return type to work correctly on platforms where 
char defaults to unsigned.

Regression testing on Intel revealed a bug in my original patch: since Scalar 
only accepts APInt initializers with a bit size that is a power of 2, we may 
need to extend some values before converting them to Scalar.  This occured for 
values representing 10-byte Intel long double data.

Tested on System z and Intel.


http://reviews.llvm.org/D18981

Files:
  include/lldb/Core/Scalar.h
  include/lldb/Symbol/Type.h
  source/Core/Scalar.cpp
  source/Expression/IRInterpreter.cpp
  source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
  source/Symbol/ClangASTContext.cpp
  unittests/Core/ScalarTest.cpp

Index: unittests/Core/ScalarTest.cpp
===
--- unittests/Core/ScalarTest.cpp
+++ unittests/Core/ScalarTest.cpp
@@ -15,7 +15,10 @@
 
 #include "gtest/gtest.h"
 
+#include "lldb/Core/Error.h"
 #include "lldb/Core/Scalar.h"
+#include "lldb/Core/DataExtractor.h"
+#include "lldb/Host/Endian.h"
 
 using namespace lldb_private;
 
@@ -30,3 +33,49 @@
 ASSERT_EQ(a >> c, a_scalar >> c_scalar);
 ASSERT_EQ(b >> c, b_scalar >> c_scalar);
 }
+
+TEST(ScalarTest, GetBytes)
+{
+int a = 0x01020304;
+long long b = 0x0102030405060708LL;
+float c = 1234567.89e42;
+double d = 1234567.89e42;
+char e[16] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 };
+char f[32] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
+   17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32 };
+Scalar a_scalar(a);
+Scalar b_scalar(b);
+Scalar c_scalar(c);
+Scalar d_scalar(d);
+Scalar e_scalar;
+Scalar f_scalar;
+DataExtractor e_data(e, sizeof(e), endian::InlHostByteOrder(), sizeof(void *));
+Error e_error = e_scalar.SetValueFromData(e_data, lldb::eEncodingUint, sizeof(e));
+DataExtractor f_data(f, sizeof(f), endian::InlHostByteOrder(), sizeof(void *));
+Error f_error = f_scalar.SetValueFromData(f_data, lldb::eEncodingUint, sizeof(f));
+ASSERT_EQ(0, memcmp(&a, a_scalar.GetBytes(), sizeof(a)));
+ASSERT_EQ(0, memcmp(&b, b_scalar.GetBytes(), sizeof(b)));
+ASSERT_EQ(0, memcmp(&c, c_scalar.GetBytes(), sizeof(c)));
+ASSERT_EQ(0, memcmp(&d, d_scalar.GetBytes(), sizeof(d)));
+ASSERT_EQ(0, e_error.Fail());
+ASSERT_EQ(0, memcmp(e, e_scalar.GetBytes(), sizeof(e)));
+ASSERT_EQ(0, f_error.Fail());
+ASSERT_EQ(0, memcmp(f, f_scalar.GetBytes(), sizeof(f)));
+}
+
+TEST(ScalarTest, CastOperations)
+{
+long long a = 0xf1f2f3f4f5f6f7f8LL;
+Scalar a_scalar(a);
+ASSERT_EQ((signed char)a, a_scalar.SChar());
+ASSERT_EQ((unsigned char)a, a_scalar.UChar());
+ASSERT_EQ((signed short)a, a_scalar.SShort());
+ASSERT_EQ((unsigned short)a, a_scalar.UShort());
+ASSERT_EQ((signed int)a, a_scalar.SInt());
+ASSERT_EQ((unsigned int)a, a_scalar.UInt());
+ASSERT_EQ((signed long)a, a_scalar.SLong());
+ASSERT_EQ((unsigned long)a, a_scalar.ULong());
+ASSERT_EQ((signed long long)a, a_scalar.SLongLong());
+ASSERT_EQ((unsigned long long)a, a_scalar.ULongLong());
+}
+
Index: source/Symbol/ClangASTContext.cpp
===
--- source/Symbol/ClangASTContext.cpp
+++ source/Symbol/ClangASTContext.cpp
@@ -72,6 +72,7 @@
 #include "lldb/Core/Module.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/RegularExpression.h"
+#include "lldb/Core/Scalar.h"
 #include "lldb/Core/StreamFile.h"
 #include "lldb/Core/ThreadSafeDenseMap.h"
 #include "lldb/Core/UniqueCStringMap.h"
@@ -8609,18 +8610,10 @@
 const uint64_t byte_size = bit_size / 8;
 if (dst_size >= byte_size)
 {
-if (bit_size == sizeof(float)*8)
-{
-float float32 = ap_float.convertToFloat();
-::memcpy (dst, &float32, byte_size);
+Scalar scalar = ap_float.bitcastToAPInt().zextOrTrunc(llvm::NextPowerOf2(byte_size) * 8);
+lldb_private::Error get_data_error;
+if (scalar.GetAsMemoryData(dst, byte_size, lldb_private::endian::InlHostByteOrder(), get_data_error))
 return byte_size;
-}
-else if (bit_size >= 64)
-{
-llvm::APInt ap_int(ap_float.bitcastToAPInt());
-::memcpy (dst, ap_int.getRawData(), byte_size);
-return byte_size;
-}
 }
 }
 }
Inde

Re: [Lldb-commits] [PATCH] D18982: Handle bit fields on big-endian systems correctly

[Ulrich Weigand via lldb-commits]

uweigand updated this revision to Diff 53605.
uweigand added a comment.

Updated interface documentation in DataExtractor.h.

Added unit test case for the DataExtractor::GetMaxU64Bitfield and 
GetMaxS64Bitfield routines.

Retested on System z and Intel.


http://reviews.llvm.org/D18982

Files:
  include/lldb/Core/DataExtractor.h
  source/Core/DataExtractor.cpp
  source/Core/ValueObject.cpp
  unittests/Core/CMakeLists.txt
  unittests/Core/DataExtractorTest.cpp

Index: unittests/Core/DataExtractorTest.cpp
===
--- unittests/Core/DataExtractorTest.cpp
+++ unittests/Core/DataExtractorTest.cpp
@@ -0,0 +1,39 @@
+//===-- DataExtractorTest.cpp ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#if defined(_MSC_VER) && (_HAS_EXCEPTIONS == 0)
+// Workaround for MSVC standard library bug, which fails to include  when
+// exceptions are disabled.
+#include 
+#endif
+
+#include "gtest/gtest.h"
+
+#include "lldb/Core/DataExtractor.h"
+
+using namespace lldb_private;
+
+TEST(DataExtractorTest, GetBitfield)
+{
+char buffer[] = { 0x01, 0x23, 0x45, 0x67 };
+DataExtractor LE(buffer, sizeof(buffer), lldb::eByteOrderLittle, sizeof(void *));
+DataExtractor BE(buffer, sizeof(buffer), lldb::eByteOrderBig, sizeof(void *));
+
+lldb::offset_t offset;
+
+offset = 0;
+ASSERT_EQ(buffer[1], LE.GetMaxU64Bitfield(&offset, sizeof(buffer), 8, 8));
+offset = 0;
+ASSERT_EQ(buffer[1], BE.GetMaxU64Bitfield(&offset, sizeof(buffer), 8, 8));
+
+offset = 0;
+ASSERT_EQ(buffer[1], LE.GetMaxS64Bitfield(&offset, sizeof(buffer), 8, 8));
+offset = 0;
+ASSERT_EQ(buffer[1], BE.GetMaxS64Bitfield(&offset, sizeof(buffer), 8, 8));
+}
Index: unittests/Core/CMakeLists.txt
===
--- unittests/Core/CMakeLists.txt
+++ unittests/Core/CMakeLists.txt
@@ -1,3 +1,4 @@
 add_lldb_unittest(LLDBCoreTests
+  DataExtractorTest.cpp
   ScalarTest.cpp
   )
Index: source/Core/ValueObject.cpp
===
--- source/Core/ValueObject.cpp
+++ source/Core/ValueObject.cpp
@@ -2146,15 +2146,19 @@
 synthetic_child_sp = GetSyntheticChild (index_const_str);
 if (!synthetic_child_sp)
 {
+uint32_t bit_field_size = to - from + 1;
+uint32_t bit_field_offset = from;
+if (GetDataExtractor().GetByteOrder() == eByteOrderBig)
+bit_field_offset = GetByteSize() * 8 - bit_field_size - bit_field_offset;
 // We haven't made a synthetic array member for INDEX yet, so
 // lets make one and cache it for any future reference.
 ValueObjectChild *synthetic_child = new ValueObjectChild (*this,
   GetCompilerType(),
   index_const_str,
   GetByteSize(),
   0,
-  to-from+1,
-  from,
+  bit_field_size,
+  bit_field_offset,
   false,
   false,
   eAddressTypeInvalid,
Index: source/Core/DataExtractor.cpp
===
--- source/Core/DataExtractor.cpp
+++ source/Core/DataExtractor.cpp
@@ -733,8 +733,11 @@
 uint64_t uval64 = GetMaxU64 (offset_ptr, size);
 if (bitfield_bit_size > 0)
 {
-if (bitfield_bit_offset > 0)
-uval64 >>= bitfield_bit_offset;
+int32_t lsbcount = bitfield_bit_offset;
+if (m_byte_order == eByteOrderBig)
+lsbcount = size * 8 - bitfield_bit_offset - bitfield_bit_size;
+if (lsbcount > 0)
+uval64 >>= lsbcount;
 uint64_t bitfield_mask = ((1ul << bitfield_bit_size) - 1);
 if (!bitfield_mask && bitfield_bit_offset == 0 && bitfield_bit_size == 64)
 return uval64;
@@ -749,8 +752,11 @@
 int64_t sval64 = GetMaxS64 (offset_ptr, size);
 if (bitfield_bit_size > 0)
 {
-if (bitfield_bit_offset > 0)
-sval64 >>= bitfield_bit_offset;
+int32_t lsbcount = bitfield_bit_offset;
+if

Re: [Lldb-commits] [PATCH] D18977: Add new ABI callback to provide fallback unwind register locations

[Ulrich Weigand via lldb-commits]

uweigand added a comment.

In http://reviews.llvm.org/D18977#400047, @clayborg wrote:

> Is the SystemZ ABI not in this patch? Looks good otherwise as long as Jason 
> Molenda is OK with the patch.


The SystemZ ABI is in http://reviews.llvm.org/D18978, which I just re-uploaded.


http://reviews.llvm.org/D18977



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

Re: [Lldb-commits] [PATCH] D18976: Handle lookup of names identifying both a variable and a type

[Ulrich Weigand via lldb-commits]

uweigand updated this revision to Diff 53553.
uweigand added a comment.

Add test case.


http://reviews.llvm.org/D18976

Files:
  packages/Python/lldbsuite/test/lang/cpp/scope/TestCppScope.py
  packages/Python/lldbsuite/test/lang/cpp/scope/main.cpp
  source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp

Index: source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
@@ -866,8 +866,11 @@
  current_id);
 }
 
-if (!context.m_found.variable)
-ClangASTSource::FindExternalVisibleDecls(context);
+// Always call into ClangASTSource::FindExternalVisibleDecls, even if we 
already found
+// some decls above.  It might be that Clang is looking for a type, but we 
have found
+// a variable of the same name instead.  Let ClangASTSource add the type 
to the result
+// list as well; Clang will filter out the decl it is actually interested 
in.
+ClangASTSource::FindExternalVisibleDecls(context);
 }
 
 void
Index: packages/Python/lldbsuite/test/lang/cpp/scope/main.cpp
===
--- packages/Python/lldbsuite/test/lang/cpp/scope/main.cpp
+++ packages/Python/lldbsuite/test/lang/cpp/scope/main.cpp
@@ -19,6 +19,10 @@
 int C::a = ;
 int a = ;
 
+// Verify that LLDB is able to parse "C::a" even when "C" exists both as a
+// type name and a variable name at the same time.
+int C = ;
+
 int main() // break here
 {
 return 0;
Index: packages/Python/lldbsuite/test/lang/cpp/scope/TestCppScope.py
===
--- packages/Python/lldbsuite/test/lang/cpp/scope/TestCppScope.py
+++ packages/Python/lldbsuite/test/lang/cpp/scope/TestCppScope.py
@@ -54,10 +54,12 @@
 'B::a': ,
 'C::a': ,
 '::a': ,
-'a': 
+'a': ,
+'::C': ,
+'C': 
 }
 
-self.assertTrue(global_variables.GetSize() == 4, "target variable 
returns all variables")
+self.assertTrue(global_variables.GetSize() == 5, "target variable 
returns all variables")
 for variable in global_variables:
 name = variable.GetName()
 self.assertTrue(name in global_variables_assert, "target variable 
returns wrong variable " + name)


Index: source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
@@ -866,8 +866,11 @@
  current_id);
 }
 
-if (!context.m_found.variable)
-ClangASTSource::FindExternalVisibleDecls(context);
+// Always call into ClangASTSource::FindExternalVisibleDecls, even if we already found
+// some decls above.  It might be that Clang is looking for a type, but we have found
+// a variable of the same name instead.  Let ClangASTSource add the type to the result
+// list as well; Clang will filter out the decl it is actually interested in.
+ClangASTSource::FindExternalVisibleDecls(context);
 }
 
 void
Index: packages/Python/lldbsuite/test/lang/cpp/scope/main.cpp
===
--- packages/Python/lldbsuite/test/lang/cpp/scope/main.cpp
+++ packages/Python/lldbsuite/test/lang/cpp/scope/main.cpp
@@ -19,6 +19,10 @@
 int C::a = ;
 int a = ;
 
+// Verify that LLDB is able to parse "C::a" even when "C" exists both as a
+// type name and a variable name at the same time.
+int C = ;
+
 int main() // break here
 {
 return 0;
Index: packages/Python/lldbsuite/test/lang/cpp/scope/TestCppScope.py
===
--- packages/Python/lldbsuite/test/lang/cpp/scope/TestCppScope.py
+++ packages/Python/lldbsuite/test/lang/cpp/scope/TestCppScope.py
@@ -54,10 +54,12 @@
 'B::a': ,
 'C::a': ,
 '::a': ,
-'a': 
+'a': ,
+'::C': ,
+'C': 
 }
 
-self.assertTrue(global_variables.GetSize() == 4, "target variable returns all variables")
+self.assertTrue(global_variables.GetSize() == 5, "target variable returns all variables")
 for variable in global_variables:
 name = variable.GetName()
 self.assertTrue(name in global_variables_assert, "target variable returns wrong variable " + name)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D18976: Handle lookup of names identifying both a variable and a type

[Ulrich Weigand via lldb-commits]

uweigand added a comment.

In http://reviews.llvm.org/D18976#399633, @labath wrote:

> I think having a self-contained test for this issue (one which does not rely 
> on internals of some system library) would be extremely valuable. Could you 
> add one?


Well, a simple way would be to just add something like

  int A, B, C;

to the lang/cpp/scope/main.cpp test case.   Would that be OK or do you prefer a 
completely separate test?


http://reviews.llvm.org/D18976



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

Re: [Lldb-commits] [PATCH] D18977: Add new ABI callback to provide fallback unwind register locations

[Ulrich Weigand via lldb-commits]

uweigand added a comment.

In http://reviews.llvm.org/D18977#399344, @jasonmolenda wrote:

> Just to be clear, my concern is we get an register location which is 
> "undefined" (I've never seen it, I don't know what it means) and now 
> SavedLocationForRegister() will say "this register is volatile, not looking 
> any further" when it used to say "register not found in this stack frame" and 
> the unwinder would keep looking down the stack for a save location.


Note that the default state of a register location if no CFI was found at all 
is "unspecified", which my patch leaves unchanged.  A register location can 
only be "undefined" if it was explicitly set to that state.  The only way this 
can happen, except for my new code in the GetFallbackRegisterLocation, is as a 
result of a DW_CFA_undefined entry in DWARF CFI.

As Tamas points out, that DWARF opcode is defined to mean the register is not 
recoverable in this frame, i.e. treating it as "volatile" should do exactly the 
right thing.  (Note that this may be mostly theoretical, since I've not seen 
any compiler ever in fact issue DW_CFA_undefined ...)

This is was I was briefly alluding to in my original comment "this might now 
theoretically also trigger when CFI contains an explicit DW_CFA_undefined, but 
it should actually do the right thing then as well."


http://reviews.llvm.org/D18977



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

Re: [Lldb-commits] [PATCH] D18977: Add new ABI callback to provide fallback unwind register locations

[Ulrich Weigand via lldb-commits]

uweigand added a comment.

OK, here's an implementation of the new approach.   In addition to the changes 
discussed, I had to add handling of undefined register locations -- this might 
now theoretically also trigger when CFI contains an explicit DW_CFA_undefined, 
but it should actually do the right thing then as well.

Everything still works on SystemZ using this approach, and I've also tested on 
Intel with no regressions.


http://reviews.llvm.org/D18977



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

Re: [Lldb-commits] [PATCH] D18977: Add new ABI callback to provide fallback unwind register locations

[Ulrich Weigand via lldb-commits]

uweigand retitled this revision from "Add new ABI callback to return CFA 
offset" to "Add new ABI callback to provide fallback unwind register locations".
uweigand updated the summary for this revision.
uweigand updated this revision to Diff 53502.

http://reviews.llvm.org/D18977

Files:
  include/lldb/Symbol/UnwindPlan.h
  include/lldb/Target/ABI.h
  source/Plugins/Process/Utility/RegisterContextLLDB.cpp
  source/Target/ABI.cpp

Index: source/Target/ABI.cpp
===
--- source/Target/ABI.cpp
+++ source/Target/ABI.cpp
@@ -205,3 +205,27 @@
 assert( !"Should never get here!" );
 return false;
 }
+
+bool
+ABI::GetFallbackRegisterLocation (const RegisterInfo *reg_info,
+  UnwindPlan::Row::RegisterLocation &unwind_regloc)
+{
+// Did the UnwindPlan fail to give us the caller's stack pointer?
+// The stack pointer is defined to be the same as THIS frame's CFA, so return the CFA value as
+// the caller's stack pointer.  This is true on x86-32/x86-64 at least.
+if (reg_info->kinds[eRegisterKindGeneric] == LLDB_REGNUM_GENERIC_SP)
+{
+unwind_regloc.SetIsCFAPlusOffset(0);
+return true;
+}
+
+// If a volatile register is being requested, we don't want to forward the next frame's register contents
+// up the stack -- the register is not retrievable at this frame.
+if (RegisterIsVolatile(reg_info))
+{
+unwind_regloc.SetUndefined();
+return true;
+}
+
+return false;
+}
Index: source/Plugins/Process/Utility/RegisterContextLLDB.cpp
===
--- source/Plugins/Process/Utility/RegisterContextLLDB.cpp
+++ source/Plugins/Process/Utility/RegisterContextLLDB.cpp
@@ -1390,45 +1390,28 @@
 }
 }
 
-if (have_unwindplan_regloc == false)
-{
-// Did the UnwindPlan fail to give us the caller's stack pointer?  
-// The stack pointer is defined to be the same as THIS frame's CFA, so return the CFA value as
-// the caller's stack pointer.  This is true on x86-32/x86-64 at least.
-
-RegisterNumber sp_regnum (m_thread, eRegisterKindGeneric, LLDB_REGNUM_GENERIC_SP);
-if (sp_regnum.GetAsKind (eRegisterKindLLDB) != LLDB_INVALID_REGNUM 
-&& sp_regnum.GetAsKind (eRegisterKindLLDB) == regnum.GetAsKind (eRegisterKindLLDB))
-{
-// make sure we won't lose precision copying an addr_t (m_cfa) into a uint64_t (.inferred_value)
-assert (sizeof (addr_t) <= sizeof (uint64_t));
-regloc.type = UnwindLLDB::RegisterLocation::eRegisterValueInferred;
-regloc.location.inferred_value = m_cfa;
-m_registers[regnum.GetAsKind (eRegisterKindLLDB)] = regloc;
-UnwindLogMsg ("supplying caller's stack pointer %s (%d) value, computed from CFA", 
-regnum.GetName(), regnum.GetAsKind (eRegisterKindLLDB));
-return UnwindLLDB::RegisterSearchResult::eRegisterFound;
-}
-}
-
 ExecutionContext exe_ctx(m_thread.shared_from_this());
 Process *process = exe_ctx.GetProcessPtr();
 if (have_unwindplan_regloc == false)
 {
-// If a volatile register is being requested, we don't want to forward the next frame's register contents
-// up the stack -- the register is not retrievable at this frame.
+// If the UnwindPlan failed to give us an unwind location for this register, we may be able to fall back
+// to some ABI-defined default.  For example, some ABIs allow to determine the caller's SP via the CFA.
+// Also, the ABI may set volatile registers to the undefined state.
 ABI *abi = process ? process->GetABI().get() : NULL;
 if (abi)
 {
 const RegisterInfo *reg_info = GetRegisterInfoAtIndex(regnum.GetAsKind (eRegisterKindLLDB));
-if (reg_info && abi->RegisterIsVolatile (reg_info))
+if (reg_info && abi->GetFallbackRegisterLocation (reg_info, unwindplan_regloc))
 {
-UnwindLogMsg ("did not supply reg location for %s (%d) because it is volatile",
+UnwindLogMsg ("supplying caller's saved %s (%d)'s location using ABI default",
   regnum.GetName(), regnum.GetAsKind (eRegisterKindLLDB));
-return UnwindLLDB::RegisterSearchResult::eRegisterIsVolatile;
+have_unwindplan_regloc = true;
 }
 }
+}
 
+if (have_unwindplan_regloc == false)
+{
 if (IsFrameZero ())
 {
 // This is frame 0 - we should return the actual live register context value
@@ -1468,6 +1451,13 @@
 return UnwindLLDB::RegisterSearchResult::eRegisterNotFound;
 }
 
+if (unwindplan_regloc.IsUndefined())
+{
+ UnwindLogMsg ("did not supply reg location for %s (%d) because it is volatile",
+   regnum.G

Re: [Lldb-commits] [PATCH] D18985: Fix test cases for big-endian systems

[Ulrich Weigand via lldb-commits]

uweigand added a comment.

In http://reviews.llvm.org/D18985#397674, @clayborg wrote:

> So many tests above are going to accept either a little endian or big endian 
> value. This will make most of these tests useless since if a little endian 
> machine fails with a big endian number we won't catch it and vice versa. So 
> we need to expect the correct value for little endian and a different but 
> correct one for big endian tests and only accept the correct one.


The new version should address this.  Each test now only accepts either the 
little-endian or big-endian result, depending on the target byte order.

> Zero seems like a bad alternate value as it could cover up a real failure. 
> Can we improve this test so that we are testing for actual values? Or can we 
> change the test by endianness and test for 16777216 for little endian and 
> something else that is not zero for big endian? We don't want zero to be 
> valid for little endian tests.


I've changed the test source value to use values such that none of the data 
elements tested by the test case is ever zero, neither on little-endian nor on 
big-endian.

Tested on both System z and Intel to verify it still works with either byte 
order.


http://reviews.llvm.org/D18985



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

Re: [Lldb-commits] [PATCH] D18985: Fix test cases for big-endian systems

[Ulrich Weigand via lldb-commits]

uweigand updated the summary for this revision.
uweigand updated this revision to Diff 53501.

http://reviews.llvm.org/D18985

Files:
  
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
  
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/main.cpp
  
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-smart-array/TestDataFormatterSmartArray.py
  
packages/Python/lldbsuite/test/functionalities/data-formatter/synthcapping/TestSyntheticCapping.py
  
packages/Python/lldbsuite/test/functionalities/data-formatter/synthcapping/main.cpp
  packages/Python/lldbsuite/test/functionalities/memory/cache/TestMemoryCache.py
  
packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
  packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
  packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
  packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py

Index: packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
@@ -387,7 +387,10 @@
 return retval
 
 elif endian == 'big':
-retval = value.encode("hex")
+retval = ""
+while value != 0:
+retval = "{:02x}".format(value & 0xff) + retval
+value = value >> 8
 if byte_size:
 # Add zero-fill to the left/front (MSB side) of the value.
 retval = ("00" * (byte_size - len(retval)/2)) + retval
Index: packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
===
--- packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
+++ packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
@@ -186,7 +186,10 @@
 
 self.assertTrue(new_object.GetValue() == "1", 'new_object == 1')
 
-data.SetData(error, 'A\0\0\0', data.GetByteOrder(), data.GetAddressByteSize())
+if data.GetByteOrder() == lldb.eByteOrderBig:
+data.SetData(error, '\0\0\0A', data.GetByteOrder(), data.GetAddressByteSize())
+else:
+data.SetData(error, 'A\0\0\0', data.GetByteOrder(), data.GetAddressByteSize())
 self.assertTrue(error.Success())
 
 data2 = lldb.SBData()
@@ -311,8 +314,8 @@
 self.assert_data(data2.GetSignedInt32, 4, -2)
 
 data2.SetDataFromSInt64Array([2, -2])
-self.assert_data(data2.GetSignedInt32, 0, 2)
-self.assert_data(data2.GetSignedInt32, 8, -2)
+self.assert_data(data2.GetSignedInt64, 0, 2)
+self.assert_data(data2.GetSignedInt64, 8, -2)
 
 data2.SetDataFromUInt32Array([1,2,3,4,5])
 self.assert_data(data2.GetUnsignedInt32, 0, 1)
Index: packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
===
--- packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
+++ packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
@@ -232,6 +232,7 @@
 
 # The bytearray_to_int utility function expects a little endian bytearray.
 if byteOrder == lldb.eByteOrderBig:
+content = bytearray(content, 'ascii')
 content.reverse()
 
 new_value = bytearray_to_int(content, byteSize)
Index: packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
===
--- packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
+++ packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
@@ -19,7 +19,13 @@
 
 self.runCmd("process launch", RUN_SUCCEEDED)
 
-self.expect('frame variable -f x i', substrs=['ff41'])
+process = self.dbg.GetSelectedTarget().GetProcess()
+
+if process.GetByteOrder() == lldb.eByteOrderLittle:
+self.expect('frame variable -f x i', substrs=['ff41'])
+else:
+self.expect('frame variable -f x i', substrs=['4100'])
+
 self.expect('frame variable c', substrs=["'A"])
 
 self.expect('frame variable x', matching=False, substrs=['3'])
Index: packages/Python/lldbsuite/test/functionalities/memory/cache/TestMemoryCache.py
===
--- packages/Python/lldbsuite/test/functionalities/memory/cache/TestMemoryCache.py
+++ packages/Python/lldbsuite/test/functionalities/memory/cache/TestMemoryCache.py
@@ -51,7 +51,7 @@
 self.assertTrue(0x0042 == int(line.split(':')[1], 0))
 
 # Change the value o

Re: [Lldb-commits] [PATCH] D18984: Fix ARM instruction emulation tests on big-endian systems

[Ulrich Weigand via lldb-commits]

uweigand added a comment.

In http://reviews.llvm.org/D18984#398486, @tberghammer wrote:

> Generally looks good with 2 minor comment inline. I also run the test suite 
> on Android ARM (little endian) and everything looked fine


Thanks for the review and test!



Comment at: source/Plugins/Instruction/ARM/EmulationStateARM.cpp:127
@@ -119,3 +126,3 @@
 else
-value = m_vfp_regs.d_regs[reg_num - dwarf_d16];
+value = m_vfp_regs.d_regs[idx - 16];
 }

Good catch!  Now fixed.


Comment at: source/Plugins/Instruction/ARM/EmulationStateARM.cpp:157
@@ -149,12 +156,3 @@
 {
-if (size > 8)
-return false;
-
-if (size <= 4)
-m_memory[p_address] = value;
-else if (size == 8)
-{
-m_memory[p_address] = (value << 32) >> 32;
-m_memory[p_address + 4] = value << 32;
-}
+m_memory[p_address] = value;
 return true;

Right, that was my intention, just forgot to actually do it ...   Now fixed.


http://reviews.llvm.org/D18984



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

Re: [Lldb-commits] [PATCH] D18984: Fix ARM instruction emulation tests on big-endian systems

[Ulrich Weigand via lldb-commits]

uweigand updated this revision to Diff 53500.

http://reviews.llvm.org/D18984

Files:
  source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
  source/Plugins/Instruction/ARM/EmulationStateARM.cpp
  source/Plugins/Instruction/ARM/EmulationStateARM.h

Index: source/Plugins/Instruction/ARM/EmulationStateARM.h
===
--- source/Plugins/Instruction/ARM/EmulationStateARM.h
+++ source/Plugins/Instruction/ARM/EmulationStateARM.h
@@ -30,10 +30,10 @@
 ReadPseudoRegisterValue (uint32_t reg_num, bool &success);
 
 bool
-StoreToPseudoAddress (lldb::addr_t p_address, uint64_t value, uint32_t size);
+StoreToPseudoAddress (lldb::addr_t p_address, uint32_t value);
 
 uint32_t
-ReadFromPseudoAddress (lldb::addr_t p_address, uint32_t size, bool &success);
+ReadFromPseudoAddress (lldb::addr_t p_address, bool &success);
 
 void
 ClearPseudoRegisters ();
@@ -82,11 +82,7 @@
 uint32_t m_gpr[17];
 struct _sd_regs
 {
-union 
-{
-uint32_t s_reg[2];
-uint64_t d_reg;
-} sd_regs[16];  // sregs 0 - 31 & dregs 0 - 15
+uint32_t s_regs[32]; // sregs 0 - 31 & dregs 0 - 15
 
 uint64_t d_regs[16]; // dregs 16-31
  
Index: source/Plugins/Instruction/ARM/EmulationStateARM.cpp
===
--- source/Plugins/Instruction/ARM/EmulationStateARM.cpp
+++ source/Plugins/Instruction/ARM/EmulationStateARM.cpp
@@ -61,11 +61,15 @@
 
 if (reg_ctx->ReadRegister (reg_info, reg_value))
 {
+uint64_t value = reg_value.GetAsUInt64();
 uint32_t idx = i - dwarf_d0;
 if (i < 16)
-m_vfp_regs.sd_regs[idx].d_reg = reg_value.GetAsUInt64();
+{
+m_vfp_regs.s_regs[idx * 2] = (uint32_t)value;
+m_vfp_regs.s_regs[idx * 2 + 1] = (uint32_t)(value >> 32);
+}
 else
-m_vfp_regs.d_regs[idx - 16] = reg_value.GetAsUInt64();
+m_vfp_regs.d_regs[idx - 16] = value;
 }
 else
 success = false;
@@ -82,16 +86,18 @@
 else if ((dwarf_s0 <= reg_num) && (reg_num <= dwarf_s31))
 {
 uint32_t idx = reg_num - dwarf_s0;
-m_vfp_regs.sd_regs[idx / 2].s_reg[idx % 2] = (uint32_t) value;
+m_vfp_regs.s_regs[idx] = (uint32_t)value;
 }
 else if ((dwarf_d0 <= reg_num) && (reg_num <= dwarf_d31))
 {
-if ((reg_num - dwarf_d0) < 16)
+uint32_t idx = reg_num - dwarf_d0;
+if (idx < 16)
 {
-m_vfp_regs.sd_regs[reg_num - dwarf_d0].d_reg = value;
+m_vfp_regs.s_regs[idx * 2] = (uint32_t)value;
+m_vfp_regs.s_regs[idx * 2 + 1] = (uint32_t)(value >> 32);
 }
 else
-m_vfp_regs.d_regs[reg_num - dwarf_d16] = value;
+m_vfp_regs.d_regs[idx - 16] = value;
 }
 else
 return false;
@@ -110,14 +116,15 @@
 else if ((dwarf_s0 <= reg_num) && (reg_num <= dwarf_s31))
 {
 uint32_t idx = reg_num - dwarf_s0;
-value = m_vfp_regs.sd_regs[idx / 2].s_reg[idx % 2];
+value = m_vfp_regs.d_regs[idx];
 }
 else if ((dwarf_d0 <= reg_num) && (reg_num <= dwarf_d31))
 {
-if ((reg_num - dwarf_d0) < 16)
-value = m_vfp_regs.sd_regs[reg_num - dwarf_d0].d_reg;
+uint32_t idx = reg_num - dwarf_d0;
+if (idx < 16)
+value = (uint64_t)m_vfp_regs.s_regs[idx * 2] | ((uint64_t)m_vfp_regs.s_regs[idx * 2 + 1] >> 32);
 else
-value = m_vfp_regs.d_regs[reg_num - dwarf_d16];
+value = m_vfp_regs.d_regs[idx - 16];
 }
 else
 success = false;
@@ -131,8 +138,8 @@
 for (int i = 0; i < 17; ++i)
 m_gpr[i] = 0;
 
-for (int i = 0; i < 16; ++i)
-m_vfp_regs.sd_regs[i].d_reg = 0;
+for (int i = 0; i < 32; ++i)
+m_vfp_regs.s_regs[i] = 0;
 
 for (int i = 0; i < 16; ++i)
 m_vfp_regs.d_regs[i] = 0;
@@ -145,23 +152,14 @@
 }
 
 bool
-EmulationStateARM::StoreToPseudoAddress (lldb::addr_t p_address, uint64_t value, uint32_t size)
+EmulationStateARM::StoreToPseudoAddress (lldb::addr_t p_address, uint32_t value)
 {
-if (size > 8)
-return false;
-
-if (size <= 4)
-m_memory[p_address] = value;
-else if (size == 8)
-{
-m_memory[p_address] = (value << 32) >> 32;
-m_memory[p_address + 4] = value << 32;
-}
+m_memory[p_address] = value;
 return true;
 }
 
 uint32_t
-EmulationStateARM::ReadFromPseudoAddress (lldb::addr_t p_address, uint32_t size, bool &success)
+EmulationStateARM::ReadFromPseudoAddress (lldb::addr_t p_address, bool &success)
 {
 std::map::iterator pos;
 uint32_t ret_val = 0;
@@ -191,25 +189,31 @@
 EmulationStateARM *pseudo_state = (EmulationStateARM *) baton;
 if (length <= 4)
 {
-uint32_t value

Re: [Lldb-commits] [PATCH] D18978: Support Linux on SystemZ as platform

[Ulrich Weigand via lldb-commits]

uweigand added a comment.

In http://reviews.llvm.org/D18978#398180, @labath wrote:

> Could you also add a core file test to `TestLinuxCore`? It should be a matter 
> of running `make_core.sh`, saving the files and creating a new test function 
> in the file (I've tried to make it simple, if you see room for improvement, 
> then let me know).
>
> I think this is especially important as probably noone here has access to 
> this hardware, so this will enable the rest of the developers to run at least 
> a basic sanity check on their changes.


Yes, that seems to work fine.  I'll add those files with the next update.

> We generally expectedFailure for things which we consider an lldb bug, and 
> skip for cases when the test simply does not apply. Platform not having 
> enough watchpoints sounds like the latter case. I see you were simply copying 
> the mips case (which does not follow this either), and it doesn't really 
> matter to me, but I just wanted to make you aware of that.


So I guess my thought was that in theory, there may be ways to support multiple 
watchpoints.  In particular, while the hardware only supports a single 
watchpoint, this may span an address range of arbitrary length.  So it may be 
possible to implement two or more watchpoints by registering a watchpoint range 
with the hardware that spans all the areas that need to be watched.  However, 
when the hardware then reports a watchpoint hit, we'd have to find out which of 
the original watchpoints is affected, and ignore cases where we get false 
positives due to hits elsewhere in the range.  This is in fact implemented in 
GDB, so it should be possible.  But an LLDB implementation of this idea seems a 
bit more complex, and certainly not something I wanted to include in the 
initial submission ...


http://reviews.llvm.org/D18978



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

Re: [Lldb-commits] [PATCH] D18977: Add new ABI callback to return CFA offset

[Ulrich Weigand via lldb-commits]

uweigand added a comment.

In http://reviews.llvm.org/D18977#398557, @clayborg wrote:

> In http://reviews.llvm.org/D18977#398157, @uweigand wrote:
>
> > In http://reviews.llvm.org/D18977#397626, @clayborg wrote:
> >
> > > I am not sure why this offset of 160 isn't represented in the unwind 
> > > info. I guess the OS unwinder that uses the EH frame info just knows that 
> > > it must adjust the CFA? That seems like a hack. It seems like the unwind 
> > > info should be fixed and the OS level unwinder should be fixed so that 
> > > the info can be used correctly without every debugger or tool that has to 
> > > parse this know about such a hack? Do you have control over the OS and 
> > > are you able to fix this? That seems like the better fix.
> >
> >
> > The offset of 160 is represented in the unwind info when computing the CFA 
> > itself.   This change is about unwinding the SP register when no explicit 
> > unwind info for SP is present.  In this case, the LLDB unwinder assumes it 
> > should set SP to the CFA, which is where the problem comes in.
>
>
> This is usually represented by the CIE (Common Information Entry) which is 
> pointed to from the FDE (Frame Description Entry). The CIE has the initial 
> state that all FDEs can share. Seems like there should be an entry for the SP 
> that says the rule to unwind it is "CFA+160"?


Well, there could be, just like there could be a default "same register" rule 
for call-saved registers so we wouldn't have to apply ABI knowledge.  However, 
none of that has been done historically on any DWARF platform I know of, mostly 
because this would duplicate information known via the ABI into every object 
file and thus waste space ...   In any case, the current state is as it is, we 
have to handle object files that currently exist.

> > Now, on s390, most frames actually have explicit unwind instructions for 
> > SP, so this special case is not even triggered.  Only for leaf functions 
> > without a stack frame can we ever see the scenario that there are no SP 
> > unwind instructions.  In those cases, the correct result on s390 is to 
> > simply leave SP unchanged (since the function did not in fact allocate a 
> > frame).

> 

> > 

> 

> > However, due to the special case in the LLDB unwinder, SP is not left 
> > unchanged, but set to the CFA (i.e. SP + 160 in this case).  This is wrong. 
> >   There are two possible ways to fix this:

> 

> > 

> 

> > - Disable the special case of setting SP to CFA on s390.   Instead, when 
> > there is no unwind info for SP, just leave it unchanged (just like any 
> > other call-saved register).   This solution is implemented in the platform 
> > unwinder (libgcc) and also in GDB.

> 

> > - Fix the special case of setting SP to CFA by actually taking the CFA bias 
> > into account.  This is what this patch implements for LLDB.

> 

> 

> There seems to be magic happening here. It seems like the CIE or FDE should 
> describe how to unwind the SP when things are tricky. We do have the notion 
> that registers that have no rule can have a default rule applied to them. 
> Currently this is only used for callee saved registers and for any such 
> registers they rule defaults to "the registers is in the register itself". 
> For volatile registers, their default rule is "the register is not 
> available". This is the part where I get fuzzy with respect to how the OS 
> unwinder works: does it have this same notion of default rules for registers? 
> If so, we should be implementing the same thing for LLDB's EH frame parser.


Actually, there are three different default rules: the ones for call-saved and 
call-clobbered registers you mention, and the special rule for the SP.   The 
platform unwinder does not care about volatile registers (because when you 
dispatch an exception, the catch point by definition must not care about the 
contents of those), but it does implement the "same register" rule for 
call-saved registers, and it does implement the special rule for SP on the 
platforms that need it.

> So a third solution is to allow the ABI plug-in to specify the default rules 
> for registers when they aren't specified. I think the ABI plug-in is where we 
> get the fact that a register is volatile or not...


Yes, that would be a solution, in fact this is the exact solution I implemented 
for GDB back in the days ...

Right now, if RegisterContextLLDB::SavedLocationForRegister finds no unwind 
info for a register, it implements (itself) the three default rules, in this 
order: if it is SP, use the CFA rule; otherwise, if the ABI says the register 
is volatile, use the "not available rule"; otherwise, say "register not found", 
which the caller interprets as "same as in the next frame".

One option to fix the s390x problem would be to instead of hard-coding the SP 
rule and the volatile check here, always call an ABI callback to define a 
"fallback register rule" by returning a UnwindPlan::Row::RegisterLocation.  The 
ABI cou

Re: [Lldb-commits] [PATCH] D18985: Fix test cases for big-endian systems

[Ulrich Weigand via lldb-commits]

uweigand added a comment.

In http://reviews.llvm.org/D18985#398171, @labath wrote:

> Just because the tests test the console interface, it doesn't mean you can't 
> use the python interface to do auxiliary tasks, like computing the 
> expectations. It sounds like you should be able to to a 
> `self.target.GetByteOrder()` to get the info you need. (use 
> `self.dbg.GetSelectedTarget()` if `self.target` happens to be empty, i don't 
> remember if it's always set).


Indeed, that seems to work fine.  Thanks for the tip!   I'll update the tests 
accordingly.


http://reviews.llvm.org/D18985



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

Re: [Lldb-commits] [PATCH] D18985: Fix test cases for big-endian systems

[Ulrich Weigand via lldb-commits]

uweigand added a comment.

In http://reviews.llvm.org/D18985#397674, @clayborg wrote:

> So many tests above are going to accept either a little endian or big endian 
> value. This will make most of these tests useless since if a little endian 
> machine fails with a big endian number we won't catch it and vice versa. So 
> we need to expect the correct value for little endian and a different but 
> correct one for big endian tests and only accept the correct one.


I fully agree this would be preferable.  Unfortunately I didn't see a 
straightforward way to detect in those test cases whether the target platform 
is big- or little-endian.  In the Python API tests this is simple, but these 
tests here just operate on the console interface.  Is there a good way to 
detect target byte order in such tests?

> Zero seems like a bad alternate value as it could cover up a real failure. 
> Can we improve this test so that we are testing for actual values? Or can we 
> change the test by endianness and test for 16777216 for little endian and 
> something else that is not zero for big endian? We don't want zero to be 
> valid for little endian tests.


The test case is a bit weird in how it (apparently deliberately) overlays 
mis-aligned synthetic fields across an integer array.  This is always going to 
behave quite differently depending on byte order.  I'll see if I can change the 
test so that values will be nonzero both on big- and on little-endian platforms.


http://reviews.llvm.org/D18985



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

Re: [Lldb-commits] [PATCH] D18977: Add new ABI callback to return CFA offset

[Ulrich Weigand via lldb-commits]

uweigand added a comment.

In http://reviews.llvm.org/D18977#397626, @clayborg wrote:

> I am not sure why this offset of 160 isn't represented in the unwind info. I 
> guess the OS unwinder that uses the EH frame info just knows that it must 
> adjust the CFA? That seems like a hack. It seems like the unwind info should 
> be fixed and the OS level unwinder should be fixed so that the info can be 
> used correctly without every debugger or tool that has to parse this know 
> about such a hack? Do you have control over the OS and are you able to fix 
> this? That seems like the better fix.


The offset of 160 is represented in the unwind info when computing the CFA 
itself.   This change is about unwinding the SP register when no explicit 
unwind info for SP is present.  In this case, the LLDB unwinder assumes it 
should set SP to the CFA, which is where the problem comes in.

Now, on s390, most frames actually have explicit unwind instructions for SP, so 
this special case is not even triggered.  Only for leaf functions without a 
stack frame can we ever see the scenario that there are no SP unwind 
instructions.  In those cases, the correct result on s390 is to simply leave SP 
unchanged (since the function did not in fact allocate a frame).

However, due to the special case in the LLDB unwinder, SP is not left 
unchanged, but set to the CFA (i.e. SP + 160 in this case).  This is wrong.   
There are two possible ways to fix this:

- Disable the special case of setting SP to CFA on s390.   Instead, when there 
is no unwind info for SP, just leave it unchanged (just like any other 
call-saved register).   This solution is implemented in the platform unwinder 
(libgcc) and also in GDB.
- Fix the special case of setting SP to CFA by actually taking the CFA bias 
into account.  This is what this patch implements for LLDB.

I've implemented the second method for LLDB since it actually seemed a bit more 
general to me (describes more precisely what actually happens on the platform), 
and also it seemed to fit nicely into the ABI scheme.

If you prefer, I can implement the first method instead.  However, since we 
cannot unconditionally disable the special case of setting SP to CFA (other 
platforms depend on that -- which is arguably the real hack to begin with), we 
would still need some ABI method to tell the unwinder whether or not the 
special case is needed.

There's no real way to "fix the unwind info", since this is not a new platform 
and binaries containing this unwind info have been in the field for more than 
15 years.  In any case, it is not clear that there is anything to "fix" -- a 
binary containing no unwind info for SP to indicate that SP does not change 
isn't really "wrong" IMO.


http://reviews.llvm.org/D18977



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

[Lldb-commits] [PATCH] D18985: Fix test cases for big-endian systems

[Ulrich Weigand via lldb-commits]

uweigand created this revision.
uweigand added reviewers: granata.enrico, clayborg.
uweigand added a subscriber: lldb-commits.

A number of test cases were failing on big-endian systems simply due to
byte order assumptions in the tests themselves, and no underlying bug
in LLDB.

These two test cases:
  tools/lldb-server/lldbgdbserverutils.py
  python_api/process/TestProcessAPI.py
actually check for big-endian target byte order, but contain Python errors
in the corresponding code paths.

This test case:
  python_api/sbdata/TestSBData.py  (first change)
could be fixed to check for big-endian target byte order.

These test case:
  python_api/sbdata/TestSBData.py  (second change)
  functionalities/memory/cache/TestMemoryCache.py
simply accessed memory with the wrong size, which wasn't noticed on LE
but fails on BE.

These test cases:
  
functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
  
functionalities/data-formatter/data-formatter-smart-array/TestDataFormatterSmartArray.py
  functionalities/data-formatter/synthcapping/TestSyntheticCapping.py
  lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
make byte order assumption, but since they're not using the Python API, I didn't
see an easy way to check for target byte order.  Instead, I've changes those 
test
to simply accept either the results see on a little-endian system or those seen
on a big-endian system.


http://reviews.llvm.org/D18985

Files:
  
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
  
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-smart-array/TestDataFormatterSmartArray.py
  
packages/Python/lldbsuite/test/functionalities/data-formatter/synthcapping/TestSyntheticCapping.py
  packages/Python/lldbsuite/test/functionalities/memory/cache/TestMemoryCache.py
  
packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
  packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
  packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
  packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py

Index: packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
@@ -387,7 +387,10 @@
 return retval
 
 elif endian == 'big':
-retval = value.encode("hex")
+retval = ""
+while value != 0:
+retval = "{:02x}".format(value & 0xff) + retval
+value = value >> 8
 if byte_size:
 # Add zero-fill to the left/front (MSB side) of the value.
 retval = ("00" * (byte_size - len(retval)/2)) + retval
Index: packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
===
--- packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
+++ packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
@@ -186,7 +186,10 @@
 
 self.assertTrue(new_object.GetValue() == "1", 'new_object == 1')
 
-data.SetData(error, 'A\0\0\0', data.GetByteOrder(), data.GetAddressByteSize())
+if data.GetByteOrder() == lldb.eByteOrderBig:
+data.SetData(error, '\0\0\0A', data.GetByteOrder(), data.GetAddressByteSize())
+else:
+data.SetData(error, 'A\0\0\0', data.GetByteOrder(), data.GetAddressByteSize())
 self.assertTrue(error.Success())
 
 data2 = lldb.SBData()
@@ -311,8 +314,8 @@
 self.assert_data(data2.GetSignedInt32, 4, -2)
 
 data2.SetDataFromSInt64Array([2, -2])
-self.assert_data(data2.GetSignedInt32, 0, 2)
-self.assert_data(data2.GetSignedInt32, 8, -2)
+self.assert_data(data2.GetSignedInt64, 0, 2)
+self.assert_data(data2.GetSignedInt64, 8, -2)
 
 data2.SetDataFromUInt32Array([1,2,3,4,5])
 self.assert_data(data2.GetUnsignedInt32, 0, 1)
Index: packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
===
--- packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
+++ packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
@@ -232,6 +232,7 @@
 
 # The bytearray_to_int utility function expects a little endian bytearray.
 if byteOrder == lldb.eByteOrderBig:
+content = bytearray(content, 'ascii')
 content.reverse()
 
 new_value = bytearray_to_int(content, byteSize)
Index: packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
===
--- packages/Python/lldbsuite/test/lang/cpp/fram

[Lldb-commits] [PATCH] D18984: Fix ARM instruction emulation tests on big-endian systems

[Ulrich Weigand via lldb-commits]

uweigand created this revision.
uweigand added a reviewer: clayborg.
uweigand added a subscriber: lldb-commits.
Herald added subscribers: rengolin, aemerson.

Running the ARM instruction emulation test on a big-endian system
would fail, since the code doesn't respect endianness properly.

In EmulateInstructionARM::TestEmulation, code assumes that an
instruction opcode read in from the test file is in target byte
order, but it was in fact read in in host byte order.

More difficult to fix, the EmulationStateARM structure models
the overlapping sregs and dregs by a union in _sd_regs.  This
only works correctly if the host is a little-endian system.
I've removed the union in favor of a simple array containing
the 32 sregs, and changed any code accessing dregs to explicitly
use the correct two sregs overlaying that dreg in the proper
target order.

Also, the EmulationStateARM::ReadPseudoMemory and WritePseudoMemory
track memory as a map of uint32_t values in host byte order, and
implement 64-bit memory accessing by splitting them up into two
uint32_t ones.  However, callers expect memory contents to be
provided in the form of a byte array (in target byte order).
This means the uint32_t contents need to be byte-swapped on
BE systems, and when splitting up a 64-bit access into two 32-bit
ones, byte order has to be respected.


http://reviews.llvm.org/D18984

Files:
  source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
  source/Plugins/Instruction/ARM/EmulationStateARM.cpp
  source/Plugins/Instruction/ARM/EmulationStateARM.h

Index: source/Plugins/Instruction/ARM/EmulationStateARM.h
===
--- source/Plugins/Instruction/ARM/EmulationStateARM.h
+++ source/Plugins/Instruction/ARM/EmulationStateARM.h
@@ -82,11 +82,7 @@
 uint32_t m_gpr[17];
 struct _sd_regs
 {
-union 
-{
-uint32_t s_reg[2];
-uint64_t d_reg;
-} sd_regs[16];  // sregs 0 - 31 & dregs 0 - 15
+uint32_t s_regs[32]; // sregs 0 - 31 & dregs 0 - 15
 
 uint64_t d_regs[16]; // dregs 16-31
  
Index: source/Plugins/Instruction/ARM/EmulationStateARM.cpp
===
--- source/Plugins/Instruction/ARM/EmulationStateARM.cpp
+++ source/Plugins/Instruction/ARM/EmulationStateARM.cpp
@@ -61,11 +61,15 @@
 
 if (reg_ctx->ReadRegister (reg_info, reg_value))
 {
+uint64_t value = reg_value.GetAsUInt64();
 uint32_t idx = i - dwarf_d0;
 if (i < 16)
-m_vfp_regs.sd_regs[idx].d_reg = reg_value.GetAsUInt64();
+{
+m_vfp_regs.s_regs[idx * 2] = (uint32_t)value;
+m_vfp_regs.s_regs[idx * 2 + 1] = (uint32_t)(value >> 32);
+}
 else
-m_vfp_regs.d_regs[idx - 16] = reg_value.GetAsUInt64();
+m_vfp_regs.d_regs[idx - 16] = value;
 }
 else
 success = false;
@@ -82,16 +86,18 @@
 else if ((dwarf_s0 <= reg_num) && (reg_num <= dwarf_s31))
 {
 uint32_t idx = reg_num - dwarf_s0;
-m_vfp_regs.sd_regs[idx / 2].s_reg[idx % 2] = (uint32_t) value;
+m_vfp_regs.s_regs[idx] = (uint32_t)value;
 }
 else if ((dwarf_d0 <= reg_num) && (reg_num <= dwarf_d31))
 {
-if ((reg_num - dwarf_d0) < 16)
+uint32_t idx = reg_num - dwarf_d0;
+if (idx < 16)
 {
-m_vfp_regs.sd_regs[reg_num - dwarf_d0].d_reg = value;
+m_vfp_regs.s_regs[idx * 2] = (uint32_t)value;
+m_vfp_regs.s_regs[idx * 2 + 1] = (uint32_t)(value >> 32);
 }
 else
-m_vfp_regs.d_regs[reg_num - dwarf_d16] = value;
+m_vfp_regs.d_regs[idx - 16] = value;
 }
 else
 return false;
@@ -110,14 +116,15 @@
 else if ((dwarf_s0 <= reg_num) && (reg_num <= dwarf_s31))
 {
 uint32_t idx = reg_num - dwarf_s0;
-value = m_vfp_regs.sd_regs[idx / 2].s_reg[idx % 2];
+value = m_vfp_regs.d_regs[idx];
 }
 else if ((dwarf_d0 <= reg_num) && (reg_num <= dwarf_d31))
 {
-if ((reg_num - dwarf_d0) < 16)
-value = m_vfp_regs.sd_regs[reg_num - dwarf_d0].d_reg;
+uint32_t idx = reg_num - dwarf_d0;
+if (idx < 16)
+value = (uint64_t)m_vfp_regs.s_regs[idx * 2] | ((uint64_t)m_vfp_regs.s_regs[idx * 2 + 1] >> 32);
 else
-value = m_vfp_regs.d_regs[reg_num - dwarf_d16];
+value = m_vfp_regs.d_regs[idx];
 }
 else
 success = false;
@@ -131,8 +138,8 @@
 for (int i = 0; i < 17; ++i)
 m_gpr[i] = 0;
 
-for (int i = 0; i < 16; ++i)
-m_vfp_regs.sd_regs[i].d_reg = 0;
+for (int i = 0; i < 32; ++i)
+m_vfp_regs.s_regs[i] = 0;
 
 for (int i = 0; i < 16; ++i)
 m_vfp_regs.d_regs[i] = 0;
@@ -147,16 +154,7 @@
 bool
 EmulationStateARM::StoreToPseudoAddress (lldb::addr_t p_address,

[Lldb-commits] [PATCH] D18983: Miscellaneous fixes for big-endian systems

[Ulrich Weigand via lldb-commits]

uweigand created this revision.
uweigand added reviewers: clayborg, granata.enrico, spyffe.
uweigand added a subscriber: lldb-commits.

This patch fixes a bunch of issues that show up on big-endian systems:

- The gnu_libstdcpp.py script doesn't follow the way libstdc++ encodes
  bit vectors: it should identify the enclosing *word* and then access
  the appropriate bit within that word.  Instead, the script simply
  operates on bytes.  This gives the same result on little-endian
  systems, but not on big-endian.

- lldb_private::formatters::WCharSummaryProvider always assumes wchar_t
  is UTF16, even though it could also be UTF8 or UTF32.  This is mostly
  not an issue on little-endian systems, but immediately fails on BE.
  Fixed by checking the size of wchar_t like WCharStringSummaryProvider
  already does.

- ClangASTContext::GetChildCompilerTypeAtIndex uses uint32_t to access
  the virtual base offset stored in the vtable, even though the size
  of this field matches the target pointer size according to the C++
  ABI.  Again, this is mostly not visible on LE, but fails on BE.

- Process::ReadStringFromMemory uses strncmp to search for a terminator
  consisting of multiple zero bytes.  This doesn't work since strncmp
  will stop already at the first zero byte.  Use memcmp instead.


http://reviews.llvm.org/D18983

Files:
  examples/synthetic/gnu_libstdcpp.py
  source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
  source/Symbol/ClangASTContext.cpp
  source/Target/Process.cpp

Index: source/Target/Process.cpp
===
--- source/Target/Process.cpp
+++ source/Target/Process.cpp
@@ -2437,7 +2437,7 @@
 // Search for a null terminator of correct size and alignment in 
bytes_read
 size_t aligned_start = total_bytes_read - total_bytes_read % 
type_width;
 for (size_t i = aligned_start; i + type_width <= total_bytes_read 
+ bytes_read; i += type_width)
-if (::strncmp(&dst[i], terminator, type_width) == 0)
+if (::memcmp(&dst[i], terminator, type_width) == 0)
 {
 error.Clear();
 return i;
Index: source/Symbol/ClangASTContext.cpp
===
--- source/Symbol/ClangASTContext.cpp
+++ source/Symbol/ClangASTContext.cpp
@@ -6038,8 +6038,9 @@
 {
 clang::CharUnits 
base_offset_offset = 
itanium_vtable_ctx->getVirtualBaseOffsetOffset(cxx_record_decl, 
base_class_decl);
 const lldb::addr_t 
base_offset_addr = vtable_ptr + base_offset_offset.getQuantity();
-const uint32_t 
base_offset = process->ReadUnsignedIntegerFromMemory(base_offset_addr, 4, 
UINT32_MAX, err);
-if (base_offset != 
UINT32_MAX)
+const uint32_t 
base_offset_size = process->GetAddressByteSize();
+const uint64_t 
base_offset = process->ReadUnsignedIntegerFromMemory(base_offset_addr, 
base_offset_size, UINT32_MAX, err);
+if (base_offset < 
UINT32_MAX)
 {
 handled = true;
 bit_offset = 
base_offset * 8;
Index: source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
===
--- source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
+++ source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
@@ -192,13 +192,33 @@
 if (error.Fail())
 return false;
 
+// Get a wchar_t basic type from the current type system
+CompilerType wchar_compiler_type = 
valobj.GetCompilerType().GetBasicTypeFromAST(lldb::eBasicTypeWChar);
+
+if (!wchar_compiler_type)
+return false;
+
+const uint32_t wchar_size = wchar_compiler_type.GetBitSize(nullptr); // 
Safe to pass NULL for exe_scope here
+
 StringPrinter::ReadBufferAndDumpToStreamOptions options(valobj);
 options.SetData(data);
 options.SetStream(&stream);
 options.SetPrefixToken("L");
 options.SetQuote('\'');
 options.SetSourceSize(1);
 options.SetBinaryZeroIsTerminator(false);
 
-return 
StringPrinter::ReadBufferAndDumpToStream(options);
+switch (wchar_size)
+{
+case 8:
+return 
StringPrinter::ReadBufferAndDumpToStream(options);
+case 16:
+return 
StringPrinter::ReadBufferAndDumpToStream(options);
+case 32:
+return 
StringPrinter::ReadBufferAndDumpToStream

[Lldb-commits] [PATCH] D18982: Handle bit fields on big-endian systems correctly

[Ulrich Weigand via lldb-commits]

uweigand created this revision.
uweigand added reviewers: granata.enrico, clayborg.
uweigand added a subscriber: lldb-commits.

Currently, the DataExtractor::GetMaxU64Bitfield and GetMaxS64Bitfield
routines assume the incoming "bitfield_bit_offset" parameter uses
little-endian bit numbering, i.e. a bitfield_bit_offset 0 refers to
a bitfield whose least-significant bit coincides with the least-
significant bit of the surrounding integer.

On many big-endian systems, however, the big-endian bit numbering
is used for bit fields.  Here, a bitfield_bit_offset 0 refers to
a bitfield whose most-significant bit conincides with the most-
significant bit of the surrounding integer.

Now, in principle LLDB could arbitrarily choose which semantics of
bitfield_bit_offset to use.  However, there are two problems with
the current approach:

- When parsing DWARF, LLDB decodes bit offsets in little-endian
  bit numbering on LE systems, but in big-endian bit numbering
  on BE systems.  Passing those offsets later on into the
  DataExtractor routines gives incorrect results on BE.

- In the interim, LLDB's type layer combines byte and bit offsets
  into a single number.  I.e. instead of recording bitfields by
  specifying the byte offset and byte size of the surrounding
  integer *plus* the bit offset of the bit field within that field,
  it simply records a single bit offset number.

  Now, note that converting from byte offset + bit offset to a
  single offset value and back is well-defined if we either use
  little-endian byte order *and* little-endian bit numbering,
  or use big-endian byte order *and* big-endian bit numbering.
  Any other combination will yield incorrect results.

Therefore, the simplest approach would seem to be to always use
the bit numbering that matches the system byte order.  This makes
storing a single bit offset valid, and makes the existing DWARF
code correct.  The only place to fix is to teach DataExtractor
to use big-endian bit numbering on big endian systems.

However, there is only additional caveat: we also get bit offsets
from LLDB synthetic bitfields.  While the exact semantics of those
doesn't seem to be well-defined, from test cases it appears that
the intent was for the user-provided synthetic bitfield offset to
always use little-endian bit numbering.  Therefore, on a big-endian
system we now have to convert those to big-endian bit numbering
to remain consistent.


http://reviews.llvm.org/D18982

Files:
  source/Core/DataExtractor.cpp
  source/Core/ValueObject.cpp

Index: source/Core/ValueObject.cpp
===
--- source/Core/ValueObject.cpp
+++ source/Core/ValueObject.cpp
@@ -2146,15 +2146,19 @@
 synthetic_child_sp = GetSyntheticChild (index_const_str);
 if (!synthetic_child_sp)
 {
+uint32_t bit_field_size = to - from + 1;
+uint32_t bit_field_offset = from;
+if (GetDataExtractor().GetByteOrder() == eByteOrderBig)
+bit_field_offset = GetByteSize() * 8 - bit_field_size - 
bit_field_offset;
 // We haven't made a synthetic array member for INDEX yet, so
 // lets make one and cache it for any future reference.
 ValueObjectChild *synthetic_child = new ValueObjectChild (*this,
   
GetCompilerType(),
   
index_const_str,
   
GetByteSize(),
   0,
-  
to-from+1,
-  from,
+  
bit_field_size,
+  
bit_field_offset,
   false,
   false,
   
eAddressTypeInvalid,
Index: source/Core/DataExtractor.cpp
===
--- source/Core/DataExtractor.cpp
+++ source/Core/DataExtractor.cpp
@@ -733,8 +733,11 @@
 uint64_t uval64 = GetMaxU64 (offset_ptr, size);
 if (bitfield_bit_size > 0)
 {
-if (bitfield_bit_offset > 0)
-uval64 >>= bitfield_bit_offset;
+int32_t lsbcount = bitfield_bit_offset;
+if (m_byte_order == eByteOrderBig)
+lsbcount = size * 8 - bitfield_bit_offset - bitfield_bit_size;
+if (lsbcount > 0)
+uval64 >>= lsbcount;
 uint64_t bitfield_mask = ((1ul << bitfield_bit_size) - 1);
 if (!bitfield_mask && bitfield_bit_offset == 0 && bitfield_bit_size == 
64)
 

[Lldb-commits] [PATCH] D18981: Fix usage of APInt.getRawData for big-endian systems

[Ulrich Weigand via lldb-commits]

uweigand created this revision.
uweigand added reviewers: clayborg, jasonmolenda, spyffe, labath, tberghammer.
uweigand added a subscriber: lldb-commits.

The Scalar implementation and a few other places in LLDB directly
access the internal implementation of APInt values using the
getRawData method.  Unfortunately, pretty much all of these places
do not handle big-endian systems correctly.  While on little-endian
machines, the pointer returned by getRawData can simply be used as
a pointer to the integer value in its natural format, no matter
what size, this is not true on big-endian systems: getRawData
actually points to an array of type uint64_t, with the first element
of the array always containing the least-significant word of the
integer.  This means that if the bitsize of that integer is smaller
than 64, we need to add an offset to the pointer returned by
getRawData in order to access the value in its natural type, and
if the bitsize is *larger* than 64, we actually have to swap the
constituent words before we can access the value in its natural type.

This patch fixes every incorrect use of getRawData in the code base.
For the most part, this is done by simply removing uses of getRawData
in the first place, and using other APInt member functions to operate
on the integer data.

This can be done in many member functions of Scalar itself, as well
as in Symbol/Type.h and in IRInterpreter::Interpret.  For the latter,
I've had to add a Scalar::MakeUnsigned routine to parallel the existing
Scalar::MakeSigned, e.g. in order to implement an unsigned divide.

The Scalar::RawUInt, Scalar::RawULong, and Scalar::RawULongLong
were already unused and can be simply removed.  I've also removed
the Scalar::GetRawBits64 function and its few users.

The one remaining user of getRawData in Scalar.cpp is GetBytes.
I've implemented all the cases described above to correctly
implement access to the underlying integer data on big-endian
systems.  GetData now simply calls GetBytes instead of reimplementing
its contents.

Finally, two places in the clang interface code were also accessing
APInt.getRawData in order to actually construct a byte representation
of an integer.  I've changes those to make use of a Scalar instead,
to avoid having to re-implement the logic there.


http://reviews.llvm.org/D18981

Files:
  include/lldb/Core/Scalar.h
  include/lldb/Symbol/Type.h
  source/Core/Scalar.cpp
  source/Expression/IRInterpreter.cpp
  source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
  source/Symbol/ClangASTContext.cpp

Index: source/Symbol/ClangASTContext.cpp
===
--- source/Symbol/ClangASTContext.cpp
+++ source/Symbol/ClangASTContext.cpp
@@ -72,6 +72,7 @@
 #include "lldb/Core/Module.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/RegularExpression.h"
+#include "lldb/Core/Scalar.h"
 #include "lldb/Core/StreamFile.h"
 #include "lldb/Core/ThreadSafeDenseMap.h"
 #include "lldb/Core/UniqueCStringMap.h"
@@ -8609,18 +8610,10 @@
 const uint64_t byte_size = bit_size / 8;
 if (dst_size >= byte_size)
 {
-if (bit_size == sizeof(float)*8)
-{
-float float32 = ap_float.convertToFloat();
-::memcpy (dst, &float32, byte_size);
+Scalar scalar = ap_float.bitcastToAPInt();
+lldb_private::Error get_data_error;
+if (scalar.GetAsMemoryData(dst, byte_size, lldb_private::endian::InlHostByteOrder(), get_data_error))
 return byte_size;
-}
-else if (bit_size >= 64)
-{
-llvm::APInt ap_int(ap_float.bitcastToAPInt());
-::memcpy (dst, ap_int.getRawData(), byte_size);
-return byte_size;
-}
 }
 }
 }
Index: source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
===
--- source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
+++ source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
@@ -1105,7 +1105,13 @@
 
 if (ConstantInt *int_initializer = dyn_cast(initializer))
 {
-memcpy (data, int_initializer->getValue().getRawData(), m_target_data->getTypeStoreSize(initializer_type));
+size_t constant_size = m_target_data->getTypeStoreSize(initializer_type);
+lldb_private::Scalar scalar = int_initializer->getValue().zextOrTrunc(constant_size * 8);
+
+lldb_private::Error get_data_error;
+if (!scalar.GetAsMemoryData(data, constant_size, lldb_private::endian::InlHostByteOrder(), get_data_error))
+return false;
+
 return true;
 }
 else if (ConstantDataArray *array_initializer = dyn_cast(initializer))
Index: source/Expression/IRInterpreter.cpp
===
--- source/Expression/IRInterpreter.

[Lldb-commits] [PATCH] D18980: Make Scalar::GetBytes and RegisterValue::GetBytes const

[Ulrich Weigand via lldb-commits]

uweigand created this revision.
uweigand added reviewers: clayborg, jasonmolenda, labath, tberghammer.
uweigand added a subscriber: lldb-commits.
Herald added a subscriber: dsanders.

Scalar::GetBytes provides a non-const access to the underlying bytes
of the scalar value, supposedly allowing for modification of those
bytes.  However, even with the current implementation, this is not
really possible.  For floating-point scalars, the pointer returned
by GetBytes refers to a temporary copy; modifications to that copy
will be simply ignored.  For integer scalars, the pointer refers
to internal memory of the APInt implementation, which isn't
supposed to be directly modifyable; GetBytes simply casts aways
the const-ness of the pointer ...

With my upcoming patch to fix Scalar::GetBytes for big-endian
systems, this problem is going to get worse, since there we need
temporary copies even for some integer scalars.  Therefore, this
patch makes Scalar::GetBytes const, fixing all those problems.

As a follow-on change, RegisterValues::GetBytes must be made const
as well.  This in turn means that the way of initializing a
RegisterValue by doing a SetType followed by writing to GetBytes
no longer works.  Instead, I've changed SetValueFromData to do
the equivalent of SetType itself, and then re-implemented
SetFromMemoryData to work on top of SetValueFromData.

There is still a need for RegisterValue::SetType, since some
platform-specific code uses it to reinterpret the contents of
an already filled RegisterValue.  To make this usage work in
all cases (even changing from a type implemented via Scalar
to a type implemented as a byte buffer), SetType now simply
copies the old contents out, and then reloads the RegisterValue
from this data using the new type via SetValueFromData.

This in turn means that there is no remaining caller of
Scalar::SetType, so it can be removed.

The only other follow-on change was in MIPS EmulateInstruction
code, where some uses of RegisterValue::GetBytes could be made
const trivially.

http://reviews.llvm.org/D18980

Files:
  include/lldb/Core/RegisterValue.h
  include/lldb/Core/Scalar.h
  source/Core/RegisterValue.cpp
  source/Core/Scalar.cpp
  source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
  source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp

Index: source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp
===
--- source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp
+++ source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp
@@ -1874,7 +1874,7 @@
 bool success = false, branch_hit = true;
 int64_t target = 0;
 RegisterValue reg_value;
-uint8_t * ptr = NULL;
+const uint8_t *ptr = NULL;
 
 uint32_t wt = m_reg_info->getEncodingValue (insn.getOperand(0).getReg());
 int64_t offset = insn.getOperand(1).getImm();
@@ -1884,7 +1884,7 @@
 return false;
 
 if (ReadRegister (eRegisterKindDWARF, dwarf_w0_mips64 + wt, reg_value))
-ptr = (uint8_t *)reg_value.GetBytes();
+ptr = (const uint8_t *)reg_value.GetBytes();
 else
 return false;
 
@@ -1897,15 +1897,15 @@
 branch_hit = false;
 break;
 case 2:
-if((*(uint16_t *)ptr == 0 && bnz) || (*(uint16_t *)ptr != 0 && !bnz))
+if ((*(const uint16_t *)ptr == 0 && bnz) || (*(const uint16_t *)ptr != 0 && !bnz))
 branch_hit = false;
 break;
 case 4:
-if((*(uint32_t *)ptr == 0 && bnz) || (*(uint32_t *)ptr != 0 && !bnz))
+if ((*(const uint32_t *)ptr == 0 && bnz) || (*(const uint32_t *)ptr != 0 && !bnz))
 branch_hit = false;
 break;
 case 8:
-if((*(uint64_t *)ptr == 0 && bnz) || (*(uint64_t *)ptr != 0 && !bnz))
+if ((*(const uint64_t *)ptr == 0 && bnz) || (*(const uint64_t *)ptr != 0 && !bnz))
 branch_hit = false;
 break;
 }
Index: source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
===
--- source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
+++ source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
@@ -2603,7 +2603,7 @@
 bool success = false, branch_hit = true;
 int32_t target = 0;
 RegisterValue reg_value;
-uint8_t * ptr = NULL;
+const uint8_t *ptr = NULL;
 
 uint32_t wt = m_reg_info->getEncodingValue (insn.getOperand(0).getReg());
 int32_t offset = insn.getOperand(1).getImm();
@@ -2613,7 +2613,7 @@
 return false;
 
 if (ReadRegister (eRegisterKindDWARF, dwarf_w0_mips + wt, reg_value))
-ptr = (uint8_t *)reg_value.GetBytes();
+ptr = (const uint8_t *)reg_value.GetBytes();
 else
 return false;
 
@@ -2626,15 +2626,15 @@
 branch_hit = false;
 

[Lldb-commits] [PATCH] D18979: Fixes for platforms that default to unsigned char

[Ulrich Weigand via lldb-commits]

uweigand created this revision.
uweigand added reviewers: spyffe, clayborg.
uweigand added a subscriber: lldb-commits.
Herald added a subscriber: aemerson.

This fixes several test case failure on s390x caused by the fact that
on this platform, the default "char" type is unsigned.

- In ClangASTContext::GetBuiltinTypeForEncodingAndBitSize we should return
  an explicit *signed* char type for encoding eEncodingSint and bit size 8,
  instead of the default platform char type (which may be unsigned).
  This fix matches existing code in ClangASTContext::GetIntTypeFromBitSize,
  and fixes the TestClangASTContext.TestBuiltinTypeForEncodingAndBitSize
  unit test case.

- The test/expression_command/char/TestExprsChar.py test case is known to
  fail on platforms defaulting to unsigned char (pr23069), and just needs
  to be xfailed on s390x like on arm.

- The test/functionalities/watchpoint/watchpoint_on_vectors/main.c test
  case defines a vector of "char" and implicitly assumes to be signed.
  Use an explicit "signed char" instead.


http://reviews.llvm.org/D18979

Files:
  packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
  
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
  source/Symbol/ClangASTContext.cpp

Index: source/Symbol/ClangASTContext.cpp
===
--- source/Symbol/ClangASTContext.cpp
+++ source/Symbol/ClangASTContext.cpp
@@ -783,8 +783,8 @@
 break;
 
 case eEncodingSint:
-if (QualTypeMatchesBitSize (bit_size, ast, ast->CharTy))
-return CompilerType (ast, ast->CharTy);
+if (QualTypeMatchesBitSize (bit_size, ast, ast->SignedCharTy))
+return CompilerType (ast, ast->SignedCharTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->ShortTy))
 return CompilerType (ast, ast->ShortTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->IntTy))
Index: 
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
===
--- 
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
+++ 
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
@@ -6,7 +6,7 @@
 // License. See LICENSE.TXT for details.
 //
 
//===--===//
-typedef char v4i8 __attribute__ ((vector_size(4)));
+typedef signed char v4i8 __attribute__ ((vector_size(4)));
 v4i8 global_vector = {1, 2, 3, 4};
 
 int
Index: packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
===
--- packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
+++ packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
@@ -57,7 +57,7 @@
 def test_default_char(self):
 self.do_test()
 
-@expectedFailureAll(archs=["arm", "aarch64"], bugnumber="llvm.org/pr23069")
+@expectedFailureAll(archs=["arm", "aarch64", "s390x"], 
bugnumber="llvm.org/pr23069")
 @expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr21765")
 def test_signed_char(self):
 self.do_test(dictionary={'CFLAGS_EXTRAS': '-fsigned-char'})


Index: source/Symbol/ClangASTContext.cpp
===
--- source/Symbol/ClangASTContext.cpp
+++ source/Symbol/ClangASTContext.cpp
@@ -783,8 +783,8 @@
 break;
 
 case eEncodingSint:
-if (QualTypeMatchesBitSize (bit_size, ast, ast->CharTy))
-return CompilerType (ast, ast->CharTy);
+if (QualTypeMatchesBitSize (bit_size, ast, ast->SignedCharTy))
+return CompilerType (ast, ast->SignedCharTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->ShortTy))
 return CompilerType (ast, ast->ShortTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->IntTy))
Index: packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
===
--- packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
+++ packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
@@ -6,7 +6,7 @@
 // License. See LICENSE.TXT for details.
 //
 //===--===//
-typedef char v4i8 __attribute__ ((vector_size(4)));
+typedef signed char v4i8 __attribute__ ((vector_size(4)));
 v4i8 global_vector = {1, 2, 3, 4};
 
 int
Index: packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
===
--- packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
+++ packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
@@ -57,7 +57

[Lldb-commits] [PATCH] D18977: Add new ABI callback to return CFA offset

[Ulrich Weigand via lldb-commits]

uweigand created this revision.
uweigand added reviewers: jasonmolenda, clayborg.
uweigand added a subscriber: lldb-commits.

If the UnwindPlan did not identify how to unwind the stack pointer
register, LLDB currently assumes it can determine to caller's SP
from the current frame's CFA.  This is true on most platforms
where CFA is by definition equal to the incoming SP at function
entry.

However, on the s390x target, we instead define the CFA to equal
the incoming SP plus an offset of 160 bytes.  This is because
our ABI defines that the caller has to provide a register save
area of size 160 bytes.  This area is allocated by the caller,
but is considered part of the callee's stack frame, and therefore
the CFA is defined as pointing to the top of this area.

In order to make stack unwinding work correctly on s390x in those
cases, LLDB common code needs to be aware of this CFA offset.
For this purpose, this patch adds a new ABI member function
CFAOffset, which defaults to always returning 0, and subtracts
that value from the CFA when unwinding the stack pointer value.

This patch in itself is a no-op for all existing platforms.
But it is a pre-requisite for adding s390x support.


http://reviews.llvm.org/D18977

Files:
  include/lldb/Target/ABI.h
  source/Plugins/Process/Utility/RegisterContextLLDB.cpp

Index: source/Plugins/Process/Utility/RegisterContextLLDB.cpp
===
--- source/Plugins/Process/Utility/RegisterContextLLDB.cpp
+++ source/Plugins/Process/Utility/RegisterContextLLDB.cpp
@@ -1390,34 +1390,36 @@
 }
 }
 
+ExecutionContext exe_ctx(m_thread.shared_from_this());
+Process *process = exe_ctx.GetProcessPtr();
+ABI *abi = process ? process->GetABI().get() : NULL;
+
 if (have_unwindplan_regloc == false)
 {
 // Did the UnwindPlan fail to give us the caller's stack pointer?  
 // The stack pointer is defined to be the same as THIS frame's CFA, so 
return the CFA value as
 // the caller's stack pointer.  This is true on x86-32/x86-64 at least.
+// On other platforms, there may be a constant offset.  Consult the 
abi->CFAOffset callback.
 
 RegisterNumber sp_regnum (m_thread, eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_SP);
 if (sp_regnum.GetAsKind (eRegisterKindLLDB) != LLDB_INVALID_REGNUM 
 && sp_regnum.GetAsKind (eRegisterKindLLDB) == regnum.GetAsKind 
(eRegisterKindLLDB))
 {
 // make sure we won't lose precision copying an addr_t (m_cfa) 
into a uint64_t (.inferred_value)
 assert (sizeof (addr_t) <= sizeof (uint64_t));
 regloc.type = UnwindLLDB::RegisterLocation::eRegisterValueInferred;
-regloc.location.inferred_value = m_cfa;
+regloc.location.inferred_value = m_cfa - (abi ? abi->CFAOffset() : 
0);
 m_registers[regnum.GetAsKind (eRegisterKindLLDB)] = regloc;
 UnwindLogMsg ("supplying caller's stack pointer %s (%d) value, 
computed from CFA", 
 regnum.GetName(), regnum.GetAsKind 
(eRegisterKindLLDB));
 return UnwindLLDB::RegisterSearchResult::eRegisterFound;
 }
 }
 
-ExecutionContext exe_ctx(m_thread.shared_from_this());
-Process *process = exe_ctx.GetProcessPtr();
 if (have_unwindplan_regloc == false)
 {
 // If a volatile register is being requested, we don't want to forward 
the next frame's register contents
 // up the stack -- the register is not retrievable at this frame.
-ABI *abi = process ? process->GetABI().get() : NULL;
 if (abi)
 {
 const RegisterInfo *reg_info = 
GetRegisterInfoAtIndex(regnum.GetAsKind (eRegisterKindLLDB));
Index: include/lldb/Target/ABI.h
===
--- include/lldb/Target/ABI.h
+++ include/lldb/Target/ABI.h
@@ -107,6 +107,16 @@
 virtual bool
 CreateDefaultUnwindPlan (UnwindPlan &unwind_plan) = 0;
 
+virtual int64_t
+CFAOffset () const
+{
+// On most targets, the CFA equals the incoming stack pointer value.
+// On some targets like SystemZ, however, the CFA is at a constant
+// offset relative to the incoming stack pointer value.
+// Return this offset.
+return 0;
+}
+
 virtual bool
 RegisterIsVolatile (const RegisterInfo *reg_info) = 0;
 


Index: source/Plugins/Process/Utility/RegisterContextLLDB.cpp
===
--- source/Plugins/Process/Utility/RegisterContextLLDB.cpp
+++ source/Plugins/Process/Utility/RegisterContextLLDB.cpp
@@ -1390,34 +1390,36 @@
 }
 }
 
+ExecutionContext exe_ctx(m_thread.shared_from_this());
+Process *process = exe_ctx.GetProcessPtr();
+ABI *abi = process ? process->GetABI().get() : NULL;
+
 if (have_unwindplan_regloc == false)
 {
 // Did the UnwindPlan fail to give us the ca

[Lldb-commits] [PATCH] D18976: Handle lookup of names identifying both a variable and a type

[Ulrich Weigand via lldb-commits]

uweigand created this revision.
uweigand added a reviewer: spyffe.
uweigand added a subscriber: lldb-commits.

In C++ code, a variable can have the same name as a type, e.g. like

int C;
struct C {
  static int a;
};

When evaluating an expression like "C::a" by the LLDB parser, clang
will call back into the external source asking for decls for the
identifier "C".  Currently, LLDB will only return the decl for the
variable C.  This in turn will cause clang to fail with an error.

(This happens for me with the lang/cpp/scope/TestCppScope.py test
case, due to a static variable C in one of the libm.so objects.)

Instead, it seems clang expects the external data source to return
*both* the variable and the type decl.  It will then choose the
appropriate one to use based on its current parsing context.

This patch changes ClangExpressionDeclMap::FindExternalVisibleDecls
to always call ClangASTSource::FindExternalVisibleDecls to possibly
identify types, even if we already found a variable of that name.


http://reviews.llvm.org/D18976

Files:
  source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp

Index: source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
@@ -866,8 +866,11 @@
  current_id);
 }
 
-if (!context.m_found.variable)
-ClangASTSource::FindExternalVisibleDecls(context);
+// Always call into ClangASTSource::FindExternalVisibleDecls, even if we 
already found
+// some decls above.  It might be that Clang is looking for a type, but we 
have found
+// a variable of the same name instead.  Let ClangASTSource add the type 
to the result
+// list as well; Clang will filter out the decl it is actually interested 
in.
+ClangASTSource::FindExternalVisibleDecls(context);
 }
 
 void


Index: source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
@@ -866,8 +866,11 @@
  current_id);
 }
 
-if (!context.m_found.variable)
-ClangASTSource::FindExternalVisibleDecls(context);
+// Always call into ClangASTSource::FindExternalVisibleDecls, even if we already found
+// some decls above.  It might be that Clang is looking for a type, but we have found
+// a variable of the same name instead.  Let ClangASTSource add the type to the result
+// list as well; Clang will filter out the decl it is actually interested in.
+ClangASTSource::FindExternalVisibleDecls(context);
 }
 
 void
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D18975: Fix unwind failures when PC points beyond the end of a function

[Ulrich Weigand via lldb-commits]

uweigand created this revision.
uweigand added a reviewer: jasonmolenda.
uweigand added a subscriber: lldb-commits.

RegisterContextLLDB::InitializeNonZerothFrame already has code to attempt
to detect and handle the case where the PC points beyond the end of a
function, but there are certain cases where this doesn't work correctly.

In fact, there are *two* different places where this detection is attempted,
and the failure is in fact a result of an unfortunate interaction between
those two separate attempts.

First, the ResolveSymbolContextForAddress routine is called with the
resolve_tail_call_address flag set to true.  This causes the routine
to internally accept a PC pointing beyond the end of a function, and
still resolving the PC to that function symbol.

Second, the InitializeNonZerothFrame routine itself maintains a
"decr_pc_and_recompute_addr_range" flag and, if that turns out to
be true, itself decrements the PC by one and searches again for
a symbol at that new PC value.

Both approaches correctly identify the symbol associated with the PC.
However, the problem is now that later on, we also need to find the
DWARF CFI record associated with the PC.  This is done in the
RegisterContextLLDB::GetFullUnwindPlanForFrame routine, and uses
the "m_current_offset_backed_up_one" member variable.

However, that variable only actually contains the PC "backed up by
one" if the *second* approach above was taken.  If the function was
already identified via the first approach above, that member variable
is *not* backed up by one but simply points to the original PC.
This in turn causes GetEHFrameUnwindPlan to not correctly identify
the DWARF CFI record associated with the PC.

Now, in many cases, if the first method had to back up the PC by one,
we *still* use the second method too, because of this piece of code:

// Or if we're in the middle of the stack (and not "above" an asynchronous 
event like sigtramp),
// and our "current" pc is the start of a function...
if (m_sym_ctx_valid
&& GetNextFrame()->m_frame_type != eTrapHandlerFrame
&& GetNextFrame()->m_frame_type != eDebuggerFrame
&& addr_range.GetBaseAddress().IsValid()
&& addr_range.GetBaseAddress().GetSection() == m_current_pc.GetSection()
&& addr_range.GetBaseAddress().GetOffset() == m_current_pc.GetOffset())
{
decr_pc_and_recompute_addr_range = true;
}

In many cases, when the PC is one beyond the end of the current function,
it will indeed then be exactly at the start of the next function.  But this
is not always the case, e.g. if there happens to be alignment padding
between the end of one function and the start of the next.

In those cases, we may sucessfully look up the function symbol via
ResolveSymbolContextForAddress, but *not* set decr_pc_and_recompute_addr_range,
and therefore fail to find the correct DWARF CFI record.

A very simple fix for this problem is to just never use the first method.
Call ResolveSymbolContextForAddress with resolve_tail_call_address set
to false, which will cause it to fail if the PC is beyond the end of
the current function; or else, identify the next function if the PC
is also at the start of the next function.  In either case, we will
then set the decr_pc_and_recompute_addr_range variable and back up the
PC anyway, but this time also find the correct DWARF CFI.


http://reviews.llvm.org/D18975

Files:
  source/Plugins/Process/Utility/RegisterContextLLDB.cpp

Index: source/Plugins/Process/Utility/RegisterContextLLDB.cpp
===
--- source/Plugins/Process/Utility/RegisterContextLLDB.cpp
+++ source/Plugins/Process/Utility/RegisterContextLLDB.cpp
@@ -470,11 +470,13 @@
 return;
 }
 
-bool resolve_tail_call_address = true; // m_current_pc can be one past the 
address range of the function...
-   // This will handle the case where 
the saved pc does not point to 
-   // a function/symbol because it is 
beyond the bounds of the correct
-   // function and there's no symbol 
there.  ResolveSymbolContextForAddress
-   // will fail to find a symbol, back 
up the pc by 1 and re-search.
+bool resolve_tail_call_address = false; // m_current_pc can be one past 
the address range of the function...
+// If the saved pc does not point 
to a function/symbol because it is
+// beyond the bounds of the 
correct function and there's no symbol there,
+// we do *not* want 
ResolveSymbolContextForAddress to back up the pc by 1,
+// because then we might not find 
the correct unwind information later.
+// Instead, let 
Resolv

[Lldb-commits] [PATCH] D18973: Find .plt section in object files generated by recent ld

[Ulrich Weigand via lldb-commits]

uweigand created this revision.
uweigand added reviewers: tberghammer, clayborg, labath.
uweigand added a subscriber: lldb-commits.

Code in ObjectFileELF::ParseTrampolineSymbols assumes that the sh_info
field of the .rel(a).plt section identifies the .plt section.

However, with recent GNU ld this is no longer true.  As a result of this:
https://sourceware.org/bugzilla/show_bug.cgi?id=18169
in object files generated with current linkers the sh_info field of
.rel(a).plt now points to the .got.plt section (or .got on some targets).

This causes LLDB to fail to identify any PLT stubs, causing a number of
test case failures.

This patch changes LLDB to simply always look for the .plt section by
name.  This should be safe across all linkers and targets.


http://reviews.llvm.org/D18973

Files:
  source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp

Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -2611,17 +2611,17 @@
 {
 assert(rel_hdr->sh_type == SHT_RELA || rel_hdr->sh_type == SHT_REL);
 
-// The link field points to the associated symbol table. The info field
-// points to the section holding the plt.
+// The link field points to the associated symbol table.
 user_id_t symtab_id = rel_hdr->sh_link;
-user_id_t plt_id = rel_hdr->sh_info;
 
 // If the link field doesn't point to the appropriate symbol name table 
then
 // try to find it by name as some compiler don't fill in the link fields.
 if (!symtab_id)
 symtab_id = GetSectionIndexByName(".dynsym");
-if (!plt_id)
-plt_id = GetSectionIndexByName(".plt");
+
+// Get PLT section.  We cannot use rel_hdr->sh_info, since current linkers
+// point that to the .got.plt or .got section instead of .plt.
+user_id_t plt_id = GetSectionIndexByName(".plt");
 
 if (!symtab_id || !plt_id)
 return 0;


Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -2611,17 +2611,17 @@
 {
 assert(rel_hdr->sh_type == SHT_RELA || rel_hdr->sh_type == SHT_REL);
 
-// The link field points to the associated symbol table. The info field
-// points to the section holding the plt.
+// The link field points to the associated symbol table.
 user_id_t symtab_id = rel_hdr->sh_link;
-user_id_t plt_id = rel_hdr->sh_info;
 
 // If the link field doesn't point to the appropriate symbol name table then
 // try to find it by name as some compiler don't fill in the link fields.
 if (!symtab_id)
 symtab_id = GetSectionIndexByName(".dynsym");
-if (!plt_id)
-plt_id = GetSectionIndexByName(".plt");
+
+// Get PLT section.  We cannot use rel_hdr->sh_info, since current linkers
+// point that to the .got.plt or .got section instead of .plt.
+user_id_t plt_id = GetSectionIndexByName(".plt");
 
 if (!symtab_id || !plt_id)
 return 0;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits