[Lldb-commits] [lldb] r265920 - Fix makefile for TestMiThreadInfo after rL265858

[Tamas Berghammer via lldb-commits]

Author: tberghammer
Date: Mon Apr 11 03:45:01 2016
New Revision: 265920

URL: http://llvm.org/viewvc/llvm-project?rev=265920&view=rev
Log:
Fix makefile for TestMiThreadInfo after rL265858

The makefile was explicitly setting LDFLAGS what is breaking some rules
in the global makefile.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/threadinfo/Makefile

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/threadinfo/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/threadinfo/Makefile?rev=265920&r1=265919&r2=265920&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/threadinfo/Makefile 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/threadinfo/Makefile 
Mon Apr 11 03:45:01 2016
@@ -1,7 +1,5 @@
 LEVEL = ../../../make
 
-LDFLAGS=-pthread
-
 CXX_SOURCES := test_threadinfo.cpp
 
 include $(LEVEL)/Makefile.rules


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

[Lldb-commits] [lldb] r265921 - Fix makefile for TestMiThreadInfo after rL265858 (2nd try)

[Tamas Berghammer via lldb-commits]

Author: tberghammer
Date: Mon Apr 11 03:54:57 2016
New Revision: 265921

URL: http://llvm.org/viewvc/llvm-project?rev=265921&view=rev
Log:
Fix makefile for TestMiThreadInfo after rL265858 (2nd try)

Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/threadinfo/Makefile

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/threadinfo/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/threadinfo/Makefile?rev=265921&r1=265920&r2=265921&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/threadinfo/Makefile 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/threadinfo/Makefile 
Mon Apr 11 03:54:57 2016
@@ -2,4 +2,6 @@ LEVEL = ../../../make
 
 CXX_SOURCES := test_threadinfo.cpp
 
+ENABLE_THREADS := YES
+
 include $(LEVEL)/Makefile.rules


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

Re: [Lldb-commits] [PATCH] D5556: [lldb] change MemoryHistoryASan::CreateInstance to not look into all modules, but only in the executable and libclang_rt.asan dynamic library

[Kuba Brecka via lldb-commits]

kubabrecka abandoned this revision.
kubabrecka added a comment.

This already landed a long time ago.


http://reviews.llvm.org/D5556



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

Re: [Lldb-commits] [PATCH] D6272: [lldb] Add @skipIfAddressSanitizerUnsupported test decorator

[Kuba Brecka via lldb-commits]

kubabrecka abandoned this revision.
kubabrecka added a comment.

This is now done properly by 1) checking out libcxx, and compiler-rt for an 
LLDB build, and 2) running tests against the just-built clang.


http://reviews.llvm.org/D6272



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

[Lldb-commits] [lldb] r265931 - Remove unintentional return

[Bhushan D. Attarde via lldb-commits]

Author: bhushan.attarde
Date: Mon Apr 11 06:19:37 2016
New Revision: 265931

URL: http://llvm.org/viewvc/llvm-project?rev=265931&view=rev
Log:
Remove unintentional return

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

Modified: lldb/trunk/source/Core/ArchSpec.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ArchSpec.cpp?rev=265931&r1=265930&r2=265931&view=diff
==
--- lldb/trunk/source/Core/ArchSpec.cpp (original)
+++ lldb/trunk/source/Core/ArchSpec.cpp Mon Apr 11 06:19:37 2016
@@ -1344,7 +1344,6 @@ cores_match (const ArchSpec::Core core1,
 {
 if (core2 == ArchSpec::eCore_mips32el || core2 == 
ArchSpec::eCore_mips32r6el)
 return true;
-return true;
 }
 break;
 


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

[Lldb-commits] [PATCH] D18965: [Driver] Fix a segfault in signal handlers

[Pavel Labath via lldb-commits]

labath created this revision.
labath added a reviewer: clayborg.
labath added a subscriber: lldb-commits.

If we recieve a SIGCONT or SIGTSTP, while the driver is shutting down (which, 
sometimes, we do,
for reasons which are not completely clear to me), we would crash to due a null 
pointer
dereference. Guard against this situation.

http://reviews.llvm.org/D18965

Files:
  tools/driver/Driver.cpp

Index: tools/driver/Driver.cpp
===
--- tools/driver/Driver.cpp
+++ tools/driver/Driver.cpp
@@ -1283,16 +1283,20 @@
 void
 sigtstp_handler (int signo)
 {
-g_driver->GetDebugger().SaveInputTerminalState();
+if (g_driver)
+g_driver->GetDebugger().SaveInputTerminalState();
+
 signal (signo, SIG_DFL);
 kill (getpid(), signo);
 signal (signo, sigtstp_handler);
 }
 
 void
 sigcont_handler (int signo)
 {
-g_driver->GetDebugger().RestoreInputTerminalState();
+if (g_driver)
+g_driver->GetDebugger().RestoreInputTerminalState();
+
 signal (signo, SIG_DFL);
 kill (getpid(), signo);
 signal (signo, sigcont_handler);


Index: tools/driver/Driver.cpp
===
--- tools/driver/Driver.cpp
+++ tools/driver/Driver.cpp
@@ -1283,16 +1283,20 @@
 void
 sigtstp_handler (int signo)
 {
-g_driver->GetDebugger().SaveInputTerminalState();
+if (g_driver)
+g_driver->GetDebugger().SaveInputTerminalState();
+
 signal (signo, SIG_DFL);
 kill (getpid(), signo);
 signal (signo, sigtstp_handler);
 }
 
 void
 sigcont_handler (int signo)
 {
-g_driver->GetDebugger().RestoreInputTerminalState();
+if (g_driver)
+g_driver->GetDebugger().RestoreInputTerminalState();
+
 signal (signo, SIG_DFL);
 kill (getpid(), signo);
 signal (signo, sigcont_handler);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D18912: sleep and retry on failure to delete temp file in tests

[Adrian McCarthy via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL265948: Retry deletion of temporary files to avoid race 
conditions on Windows. (authored by amccarth).

Changed prior to commit:
  http://reviews.llvm.org/D18912?vs=53100&id=53249#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18912

Files:
  lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py

Index: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
@@ -1049,23 +1049,13 @@
 # it silently replaces the destination.  Ultimately 
this means that atomic renames are not
 # guaranteed to be possible on Windows, but we need 
this to work anyway, so just remove the
 # destination first if it already exists.
-os.remove(dst)
+remove_file(dst)
 
 os.rename(src, dst)
 else:
 # success!  (and we don't want log files) delete log files
 for log_file in log_files_for_this_test:
-try:
-os.unlink(log_file)
-except:
-# We've seen consistent unlink failures on Windows, 
perhaps because the
-# just-created log file is being scanned by anti-virus.  
Empirically, this
-# sleep-and-retry approach allows tests to succeed much 
more reliably.
-# Attempts to figure out exactly what process was still 
holding a file handle
-# have failed because running instrumentation like Process 
Monitor seems to
-# slow things down enough that the problem becomes much 
less consistent.
-time.sleep(0.5)
-os.unlink(log_file)
+remove_file(log_file)
 
 # 
 # Config. methods supported through a plugin interface
@@ -1996,4 +1986,17 @@
 @classmethod
 def RemoveTempFile(cls, file):
 if os.path.exists(file):
+remove_file(file)
+
+# On Windows, the first attempt to delete a recently-touched file can fail
+# because of a race with antimalware scanners.  This function will detect a
+# failure and retry.
+def remove_file(file, num_retries = 1, sleep_duration = 0.5):
+for i in range(num_retries+1):
+try:
 os.remove(file)
+return True
+except:
+time.sleep(sleep_duration)
+continue
+return False


Index: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
@@ -1049,23 +1049,13 @@
 # it silently replaces the destination.  Ultimately this means that atomic renames are not
 # guaranteed to be possible on Windows, but we need this to work anyway, so just remove the
 # destination first if it already exists.
-os.remove(dst)
+remove_file(dst)
 
 os.rename(src, dst)
 else:
 # success!  (and we don't want log files) delete log files
 for log_file in log_files_for_this_test:
-try:
-os.unlink(log_file)
-except:
-# We've seen consistent unlink failures on Windows, perhaps because the
-# just-created log file is being scanned by anti-virus.  Empirically, this
-# sleep-and-retry approach allows tests to succeed much more reliably.
-# Attempts to figure out exactly what process was still holding a file handle
-# have failed because running instrumentation like Process Monitor seems to
-# slow things down enough that the problem becomes much less consistent.
-time.sleep(0.5)
-os.unlink(log_file)
+remove_file(log_file)
 
 # 
 # Config. methods supported through a plugin interface
@@ -1996,4 +1986,17 @@
 @classmethod
 def RemoveTempFile(cls, file):
 if os.path.exists(file):
+remove_file(file)
+
+# On Windows, the first attempt to delete a recently-touched file can fail
+# because of a race with antimalware scanners.  This function will detect a
+# failure and retry.
+def remove_file(file, num_retries = 1, sleep_duration = 0.5):
+for i in range(num_retries+1):
+try:
 os.remove(file)
+return True
+except:
+time.sleep(sleep_duration)

[Lldb-commits] [lldb] r265948 - Retry deletion of temporary files to avoid race conditions on Windows.

[Adrian McCarthy via lldb-commits]

Author: amccarth
Date: Mon Apr 11 10:21:01 2016
New Revision: 265948

URL: http://llvm.org/viewvc/llvm-project?rev=265948&view=rev
Log:
Retry deletion of temporary files to avoid race conditions on Windows.

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

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

Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py?rev=265948&r1=265947&r2=265948&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Mon Apr 11 10:21:01 
2016
@@ -1049,23 +1049,13 @@ class Base(unittest2.TestCase):
 # it silently replaces the destination.  Ultimately 
this means that atomic renames are not
 # guaranteed to be possible on Windows, but we need 
this to work anyway, so just remove the
 # destination first if it already exists.
-os.remove(dst)
+remove_file(dst)
 
 os.rename(src, dst)
 else:
 # success!  (and we don't want log files) delete log files
 for log_file in log_files_for_this_test:
-try:
-os.unlink(log_file)
-except:
-# We've seen consistent unlink failures on Windows, 
perhaps because the
-# just-created log file is being scanned by anti-virus.  
Empirically, this
-# sleep-and-retry approach allows tests to succeed much 
more reliably.
-# Attempts to figure out exactly what process was still 
holding a file handle
-# have failed because running instrumentation like Process 
Monitor seems to
-# slow things down enough that the problem becomes much 
less consistent.
-time.sleep(0.5)
-os.unlink(log_file)
+remove_file(log_file)
 
 # 
 # Config. methods supported through a plugin interface
@@ -1996,4 +1986,17 @@ class TestBase(Base):
 @classmethod
 def RemoveTempFile(cls, file):
 if os.path.exists(file):
+remove_file(file)
+
+# On Windows, the first attempt to delete a recently-touched file can fail
+# because of a race with antimalware scanners.  This function will detect a
+# failure and retry.
+def remove_file(file, num_retries = 1, sleep_duration = 0.5):
+for i in range(num_retries+1):
+try:
 os.remove(file)
+return True
+except:
+time.sleep(sleep_duration)
+continue
+return False


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

Re: [Lldb-commits] [PATCH] D18965: [Driver] Fix a segfault in signal handlers

[Pavel Labath via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL265958: [Driver] Fix a segfault in signal handlers (authored 
by labath).

Changed prior to commit:
  http://reviews.llvm.org/D18965?vs=53239&id=53265#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18965

Files:
  lldb/trunk/tools/driver/Driver.cpp

Index: lldb/trunk/tools/driver/Driver.cpp
===
--- lldb/trunk/tools/driver/Driver.cpp
+++ lldb/trunk/tools/driver/Driver.cpp
@@ -1283,16 +1283,20 @@
 void
 sigtstp_handler (int signo)
 {
-g_driver->GetDebugger().SaveInputTerminalState();
+if (g_driver)
+g_driver->GetDebugger().SaveInputTerminalState();
+
 signal (signo, SIG_DFL);
 kill (getpid(), signo);
 signal (signo, sigtstp_handler);
 }
 
 void
 sigcont_handler (int signo)
 {
-g_driver->GetDebugger().RestoreInputTerminalState();
+if (g_driver)
+g_driver->GetDebugger().RestoreInputTerminalState();
+
 signal (signo, SIG_DFL);
 kill (getpid(), signo);
 signal (signo, sigcont_handler);


Index: lldb/trunk/tools/driver/Driver.cpp
===
--- lldb/trunk/tools/driver/Driver.cpp
+++ lldb/trunk/tools/driver/Driver.cpp
@@ -1283,16 +1283,20 @@
 void
 sigtstp_handler (int signo)
 {
-g_driver->GetDebugger().SaveInputTerminalState();
+if (g_driver)
+g_driver->GetDebugger().SaveInputTerminalState();
+
 signal (signo, SIG_DFL);
 kill (getpid(), signo);
 signal (signo, sigtstp_handler);
 }
 
 void
 sigcont_handler (int signo)
 {
-g_driver->GetDebugger().RestoreInputTerminalState();
+if (g_driver)
+g_driver->GetDebugger().RestoreInputTerminalState();
+
 signal (signo, SIG_DFL);
 kill (getpid(), signo);
 signal (signo, sigcont_handler);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r265958 - [Driver] Fix a segfault in signal handlers

[Pavel Labath via lldb-commits]

Author: labath
Date: Mon Apr 11 11:40:09 2016
New Revision: 265958

URL: http://llvm.org/viewvc/llvm-project?rev=265958&view=rev
Log:
[Driver] Fix a segfault in signal handlers

Summary:
If we recieve a SIGCONT or SIGTSTP, while the driver is shutting down (which, 
sometimes, we do,
for reasons which are not completely clear to me), we would crash to due a null 
pointer
dereference. Guard against this situation.

Reviewers: clayborg

Subscribers: lldb-commits

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

Modified:
lldb/trunk/tools/driver/Driver.cpp

Modified: lldb/trunk/tools/driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/driver/Driver.cpp?rev=265958&r1=265957&r2=265958&view=diff
==
--- lldb/trunk/tools/driver/Driver.cpp (original)
+++ lldb/trunk/tools/driver/Driver.cpp Mon Apr 11 11:40:09 2016
@@ -1283,7 +1283,9 @@ sigint_handler (int signo)
 void
 sigtstp_handler (int signo)
 {
-g_driver->GetDebugger().SaveInputTerminalState();
+if (g_driver)
+g_driver->GetDebugger().SaveInputTerminalState();
+
 signal (signo, SIG_DFL);
 kill (getpid(), signo);
 signal (signo, sigtstp_handler);
@@ -1292,7 +1294,9 @@ sigtstp_handler (int signo)
 void
 sigcont_handler (int signo)
 {
-g_driver->GetDebugger().RestoreInputTerminalState();
+if (g_driver)
+g_driver->GetDebugger().RestoreInputTerminalState();
+
 signal (signo, SIG_DFL);
 kill (getpid(), signo);
 signal (signo, sigcont_handler);


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

[Lldb-commits] [lldb] r265959 - Mark TestPrintStackTraces as flaky on android arm

[Pavel Labath via lldb-commits]

Author: labath
Date: Mon Apr 11 11:50:08 2016
New Revision: 265959

URL: http://llvm.org/viewvc/llvm-project?rev=265959&view=rev
Log:
Mark TestPrintStackTraces as flaky on android arm

Modified:

lldb/trunk/packages/Python/lldbsuite/test/python_api/lldbutil/process/TestPrintStackTraces.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/python_api/lldbutil/process/TestPrintStackTraces.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/lldbutil/process/TestPrintStackTraces.py?rev=265959&r1=265958&r2=265959&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/python_api/lldbutil/process/TestPrintStackTraces.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/python_api/lldbutil/process/TestPrintStackTraces.py
 Mon Apr 11 11:50:08 2016
@@ -29,6 +29,7 @@ class ThreadsStackTracesTestCase(TestBas
 #hence unwinding fail when we are stopped in __thread_start
 @expectedFailureAll(triple = 'mips*')
 @expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24778")
+@expectedFlakeyAndroid("llvm.org/26492", archs=["arm"])
 @add_test_categories(['pyapi'])
 def test_stack_traces(self):
 """Test SBprocess and SBThread APIs with printing of the stack 
traces."""


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

[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

[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] 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] 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] 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] 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] 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] 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] 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] 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] 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] [lldb] r265979 - Add support for additional NSArray formatters

[Enrico Granata via lldb-commits]

Author: enrico
Date: Mon Apr 11 13:46:37 2016
New Revision: 265979

URL: http://llvm.org/viewvc/llvm-project?rev=265979&view=rev
Log:
Add support for additional NSArray formatters

Modified:
lldb/trunk/source/Plugins/Language/ObjC/Cocoa.h
lldb/trunk/source/Plugins/Language/ObjC/NSArray.cpp

Modified: lldb/trunk/source/Plugins/Language/ObjC/Cocoa.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/ObjC/Cocoa.h?rev=265979&r1=265978&r2=265979&view=diff
==
--- lldb/trunk/source/Plugins/Language/ObjC/Cocoa.h (original)
+++ lldb/trunk/source/Plugins/Language/ObjC/Cocoa.h Mon Apr 11 13:46:37 2016
@@ -13,6 +13,7 @@
 #include "lldb/Core/Stream.h"
 #include "lldb/Core/ValueObject.h"
 #include "lldb/DataFormatters/TypeSummary.h"
+#include "lldb/DataFormatters/TypeSynthetic.h"
 #include "lldb/Target/ObjCLanguageRuntime.h"
 
 namespace lldb_private {
@@ -88,6 +89,16 @@ namespace lldb_private {
 
 SyntheticChildrenFrontEnd*
 NSExceptionSyntheticFrontEndCreator (CXXSyntheticChildren*, 
lldb::ValueObjectSP valobj_sp);
+
+class NSArray_Additionals
+{
+public:
+static std::map&
+GetAdditionalSummaries ();
+
+static std::map&
+GetAdditionalSynthetics ();
+};
 } // namespace formatters
 } // namespace lldb_private
 

Modified: lldb/trunk/source/Plugins/Language/ObjC/NSArray.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/ObjC/NSArray.cpp?rev=265979&r1=265978&r2=265979&view=diff
==
--- lldb/trunk/source/Plugins/Language/ObjC/NSArray.cpp (original)
+++ lldb/trunk/source/Plugins/Language/ObjC/NSArray.cpp Mon Apr 11 13:46:37 2016
@@ -35,6 +35,20 @@ using namespace lldb_private::formatters
 
 namespace  lldb_private {
 namespace formatters {
+std::map&
+NSArray_Additionals::GetAdditionalSummaries ()
+{
+static std::map 
g_map;
+return g_map;
+}
+
+std::map&
+NSArray_Additionals::GetAdditionalSynthetics ()
+{
+static std::map g_map;
+return g_map;
+}
+
 class NSArrayMSyntheticFrontEnd : public SyntheticChildrenFrontEnd
 {
 public:
@@ -322,7 +336,14 @@ lldb_private::formatters::NSArraySummary
 return false;
 }
 else
-return false;
+{
+auto& map(NSArray_Additionals::GetAdditionalSummaries());
+auto iter = map.find(class_name), end = map.end();
+if (iter != end)
+return iter->second(valobj, stream, options);
+else
+return false;
+}
 
 std::string prefix,suffix;
 if (Language* language = Language::FindPlugin(options.GetLanguage()))
@@ -746,7 +767,7 @@ lldb_private::formatters::NSArray1Synthe
 return lldb::ValueObjectSP();
 }
 
-SyntheticChildrenFrontEnd* 
lldb_private::formatters::NSArraySyntheticFrontEndCreator 
(CXXSyntheticChildren*, lldb::ValueObjectSP valobj_sp)
+SyntheticChildrenFrontEnd* 
lldb_private::formatters::NSArraySyntheticFrontEndCreator 
(CXXSyntheticChildren* synth, lldb::ValueObjectSP valobj_sp)
 {
 if (!valobj_sp)
 return nullptr;
@@ -803,6 +824,13 @@ SyntheticChildrenFrontEnd* lldb_private:
 else
 return (new NSArrayMSyntheticFrontEnd_109(valobj_sp));
 }
+else
+{
+auto& map(NSArray_Additionals::GetAdditionalSynthetics());
+auto iter = map.find(class_name), end = map.end();
+if (iter != end)
+return iter->second(synth, valobj_sp);
+}
 
 return nullptr;
 }


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

[Lldb-commits] [lldb] r265978 - Add a formatter for zero-sized NSData

[Enrico Granata via lldb-commits]

Author: enrico
Date: Mon Apr 11 13:46:26 2016
New Revision: 265978

URL: http://llvm.org/viewvc/llvm-project?rev=265978&view=rev
Log:
Add a formatter for zero-sized NSData

Modified:
lldb/trunk/source/Plugins/Language/ObjC/Cocoa.cpp

Modified: lldb/trunk/source/Plugins/Language/ObjC/Cocoa.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/ObjC/Cocoa.cpp?rev=265978&r1=265977&r2=265978&view=diff
==
--- lldb/trunk/source/Plugins/Language/ObjC/Cocoa.cpp (original)
+++ lldb/trunk/source/Plugins/Language/ObjC/Cocoa.cpp Mon Apr 11 13:46:26 2016
@@ -833,6 +833,10 @@ lldb_private::formatters::NSDataSummaryP
 if (error.Fail())
 return false;
 }
+else if (!strcmp(class_name, "_NSZeroData"))
+{
+value = 0;
+}
 else
 return false;
 


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

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

[Greg Clayton via lldb-commits]

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

Other ELF experts should OK this one as well, but looks good to me though.


http://reviews.llvm.org/D18973



___
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

[Greg Clayton via lldb-commits]

clayborg added a comment.

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.


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] D18886: Reset continue_after_async only if neither SIGINIT nor SIGSTOP received

[Adrian McCarthy via lldb-commits]

amccarth added a subscriber: amccarth.
amccarth added a comment.

FYI:  According to git bisect, this patch seems to have introduced a new test 
failure on Windows.


http://reviews.llvm.org/D18886



___
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

[Greg Clayton via lldb-commits]

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

Just a few questions on why read watchpoints were being disabled in the few 
SBValue::Watch() calls. Other than that it looks good. Is it possible to revert 
the read watchpoint changes, or is it needed for SystemZ?



Comment at: 
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_events/TestWatchpointEvents.py:62
@@ -61,3 +61,3 @@
 error = lldb.SBError()
-local_watch = local_var.Watch(True, True, True, error)
+local_watch = local_var.Watch(True, False, True, error)
 if not error.Success():

I realize this test isn't actually using the watchpoint, it is just testing it, 
but why is this change needed? Does SystemZ not support read watchpoints or 
something?


Comment at: 
packages/Python/lldbsuite/test/python_api/watchpoint/TestWatchpointIter.py:61
@@ -60,3 +60,3 @@
 error = lldb.SBError();
-watchpoint = value.Watch(True, True, True, error)
+watchpoint = value.Watch(True, False, True, error)
 self.assertTrue(value and watchpoint,

This test just tests hitting writes to a variable, but why is this change 
needed? Does SystemZ not support read watchpoints or something?


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] D18979: Fixes for platforms that default to unsigned char

[Greg Clayton via lldb-commits]

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

Looks good.


http://reviews.llvm.org/D18979



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

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

[Greg Clayton via lldb-commits]

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

Looks good.


http://reviews.llvm.org/D18981



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

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

[Greg Clayton via lldb-commits]

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

Looks good.


http://reviews.llvm.org/D18980



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

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

[Greg Clayton via lldb-commits]

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

Looks good as long as all tests still pass on all other systems.


http://reviews.llvm.org/D18982



___
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

[Greg Clayton via lldb-commits]

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

Looks good as long as all tests pass on all other systems.


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] D18983: Miscellaneous fixes for big-endian systems

[Greg Clayton via lldb-commits]

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

Looks good.


http://reviews.llvm.org/D18983



___
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

[Greg Clayton via lldb-commits]

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

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.



Comment at: 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py:75-79
@@ -74,6 +74,7 @@
 # check that we get the two real vars and the fake_a variables
+# note that the value of fake_a depends on target byte order
 self.expect("frame variable f00_1",
-substrs = ['r = 33',
-   'fake_a = 16777216',
-   'a = 0']);
+patterns = ['r = 33',
+'fake_a = (16777216|0)',
+'a = 0']);
 

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.


Comment at: 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py:87
@@ -85,3 +86,3 @@
 self.expect('frame variable f00_1.fake_a',
-substrs = ['16777216'])
+patterns = ['(16777216|0)'])
 

ditto


Comment at: 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py:91
@@ -89,3 +90,3 @@
 self.expect('frame variable f00_1[1]',
-substrs = ['16777216'])
+patterns = ['(16777216|0)'])
 

ditto


Comment at: 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py:96
@@ -94,3 +95,3 @@
 self.expect('frame variable f00_1',
-substrs = ['fake_a=16777216'])
+patterns = ['fake_a=(16777216|0)'])
 self.runCmd("type summary add --summary-string \"fake_a=${svar[1]}\" 
foo")

ditto


Comment at: 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py:99
@@ -97,3 +98,3 @@
 self.expect('frame variable f00_1',
-substrs = ['fake_a=16777216'])
+patterns = ['fake_a=(16777216|0)'])
 

ditto


Comment at: 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py:109
@@ +108,3 @@
+patterns = ['r = 33',
+'fake_a = (16777216|256)',
+'a = 1']);

We should expect one thing for little endian and one for big, don't accept 
either.


Comment at: 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py:116
@@ +115,3 @@
+patterns = ['r = 33',
+'fake_a = (16777217|71680)',
+'a = 280']);

We should expect one thing for little endian and one for big, don't accept 
either.


Comment at: 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py:122
@@ +121,3 @@
+patterns = ['r = 45',
+'fake_a = (218103808|3072)',
+'a = 12'])

We should expect one thing for little endian and one for big, don't accept 
either.


Comment at: 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py:135
@@ +134,3 @@
+patterns = ['r = 45',
+'fake_a = (218103808|3072)',
+'a = 12'])

We should expect one thing for little endian and one for big, don't accept 
either.


Comment at: 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py:147
@@ +146,3 @@
+patterns = ['r = 45',
+'fake_a = (218103808|3072)',
+'a = 12'])

We should expect one thing for little 

[Lldb-commits] [lldb] r266001 - Add support for resolving dynamic types of extended ObjC tagged pointers

[Enrico Granata via lldb-commits]

Author: enrico
Date: Mon Apr 11 16:50:35 2016
New Revision: 266001

URL: http://llvm.org/viewvc/llvm-project?rev=266001&view=rev
Log:
Add support for resolving dynamic types of extended ObjC tagged pointers

rdar://problem/24401051


Modified:

lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp

lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.h

Modified: 
lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp?rev=266001&r1=266000&r2=266001&view=diff
==
--- 
lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
 Mon Apr 11 16:50:35 2016
@@ -2034,6 +2034,74 @@ AppleObjCRuntimeV2::TaggedPointerVendorV
 if (error.Fail())
 return new TaggedPointerVendorLegacy(runtime);
 
+// try to detect the "extended tagged pointer" variables - if any are 
missing, use the non-extended vendor
+do
+{
+auto objc_debug_taggedpointer_ext_mask = 
ExtractRuntimeGlobalSymbol(process,
+
ConstString("objc_debug_taggedpointer_ext_mask"),
+
objc_module_sp,
+
error);
+if (error.Fail())
+break;
+
+auto objc_debug_taggedpointer_ext_slot_shift = 
ExtractRuntimeGlobalSymbol(process,
+   
   ConstString("objc_debug_taggedpointer_ext_slot_shift"),
+   
   objc_module_sp,
+   
   error,
+   
   true,
+   
   4);
+if (error.Fail())
+break;
+
+auto objc_debug_taggedpointer_ext_slot_mask = 
ExtractRuntimeGlobalSymbol(process,
+   
  ConstString("objc_debug_taggedpointer_ext_slot_mask"),
+   
  objc_module_sp,
+   
  error,
+   
  true,
+   
  4);
+if (error.Fail())
+break;
+
+auto objc_debug_taggedpointer_ext_classes = 
ExtractRuntimeGlobalSymbol(process,
+   
ConstString("objc_debug_taggedpointer_ext_classes"),
+   
objc_module_sp,
+   
error,
+   
false);
+if (error.Fail())
+break;
+
+auto objc_debug_taggedpointer_ext_payload_lshift = 
ExtractRuntimeGlobalSymbol(process,
+   
   ConstString("objc_debug_taggedpointer_ext_payload_lshift"),
+   
   objc_module_sp,
+   
   error,
+   
   true,
+   
   4);
+if (error.Fail())
+break;
+
+auto objc_debug_taggedpointer_ext_payload_rshift = 
ExtractRuntimeGlobalSymbol(process,
+   
   ConstString("objc_debug_taggedpointer_ext_payload_rshift"),
+   
   objc_module_sp,
+   
   error,
+   
   true,
+   
   4);
+if (error.Fail())
+break;
+
+return new TaggedPointerVendo

Re: [Lldb-commits] [PATCH] D18848: Add PDBASTParser and parse type information from PDB

[Zachary Turner via lldb-commits]

Thanks.  One more question.  Does SymbolFile::FindTypes need to be able to
handle the case of a null type name (which I guess would indicate to find
every type)?

On Fri, Apr 8, 2016 at 3:24 PM Greg Clayton  wrote:

> clayborg added a comment.
>
> In http://reviews.llvm.org/D18848#395933, @zturner wrote:
>
> > I mean for example if someone calls `FindTypes(..., "char", ...);`
> >
> > Should a `TypeSP` go into the map?
>
>
> No you don't have to make one up if you don't have one. At least this is
> what the DWARF parser does. The main problem is the definition for "char"
> can be signed or unsigned depending on how your translation unit was
> compiled. Probably some other char types can vary as well. No expressions
> will ask for built in types since the expression parser already knows about
> them. And it is useful to try and lookup "char" in a SymbolFile to see what
> the notion that that symbol file has for "char" (signed or unsigned).
>
> So if you actually have one, return it. Or if PDB always has some around
> and it has some unique identifiers for the builtin types you can easily
> create them from your clang::ASTContext with the "ast->IntTy" and the many
> other built int types. But if you don't have any, don't worry about
> creating them from nothing.
>
>
> http://reviews.llvm.org/D18848
>
>
>
>
___
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

[Greg Clayton via lldb-commits]

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

Ok, then setting write only watchpoints should be fine for those tests/


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] D18848: Add PDBASTParser and parse type information from PDB

[Greg Clayton via lldb-commits]

clayborg added a comment.

In http://reviews.llvm.org/D18848#397787, @zturner wrote:

> Thanks.  One more question.  Does SymbolFile::FindTypes need to be able to 
> handle the case of a null type name (which I guess would indicate to find 
> every type)?


No. It should handle the request without crashing and it should return zero 
matches, but you don't need to find every type. If we ever did, we would do 
this with regular expressions.


http://reviews.llvm.org/D18848



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

Re: [Lldb-commits] [PATCH] D18886: Reset continue_after_async only if neither SIGINIT nor SIGSTOP received

[Oleksiy Vyalov via lldb-commits]

ovyalov added a comment.

In http://reviews.llvm.org/D18886#397637, @amccarth wrote:

> FYI:  According to git bisect, this patch seems to have introduced a new test 
> failure on Windows.


Thanks for the report - will fix today.


http://reviews.llvm.org/D18886



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

Re: [Lldb-commits] [PATCH] D18886: Reset continue_after_async only if neither SIGINIT nor SIGSTOP received

[Adrian McCarthy via lldb-commits]

amccarth added a comment.

It's weird in that, if you run the test independently, it passes.  But if you 
run it with the multiprocess test runner (ninja check-lldb), then it fails on 
this line:

self.fail("Setting a breakpoint generated an unexpected event: %s" % 
lldb.SBDebugger.StateAsCString(lldb.SBProcess.GetStateFromEvent(event)))

The state in this case is stopped.


http://reviews.llvm.org/D18886



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

[Lldb-commits] [lldb] r266023 - Fixed Variable::GetDecl() and Variable::GetDeclContext() to check the "Type *" before using it so we don't crash if a variable's type can't be realized which happens mo

[Greg Clayton via lldb-commits]

Author: gclayton
Date: Mon Apr 11 19:06:27 2016
New Revision: 266023

URL: http://llvm.org/viewvc/llvm-project?rev=266023&view=rev
Log:
Fixed Variable::GetDecl() and Variable::GetDeclContext() to check the "Type *" 
before using it so we don't crash if a variable's type can't be realized which 
happens more often recently due to -gmodules.




Modified:
lldb/trunk/source/Symbol/Variable.cpp

Modified: lldb/trunk/source/Symbol/Variable.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/Variable.cpp?rev=266023&r1=266022&r2=266023&view=diff
==
--- lldb/trunk/source/Symbol/Variable.cpp (original)
+++ lldb/trunk/source/Symbol/Variable.cpp Mon Apr 11 19:06:27 2016
@@ -244,16 +244,22 @@ CompilerDeclContext
 Variable::GetDeclContext ()
 {
 Type *type = GetType();
-return type->GetSymbolFile()->GetDeclContextContainingUID(GetID());
+if (type)
+return type->GetSymbolFile()->GetDeclContextContainingUID(GetID());
+return CompilerDeclContext();
 }
 
 CompilerDecl
 Variable::GetDecl ()
 {
+CompilerDecl decl;
 Type *type = GetType();
-CompilerDecl decl = type->GetSymbolFile()->GetDeclForUID(GetID());
-if (decl)
-decl.GetTypeSystem()->DeclLinkToObject(decl.GetOpaqueDecl(), 
shared_from_this());
+if (type)
+{
+decl = type->GetSymbolFile()->GetDeclForUID(GetID());
+if (decl)
+decl.GetTypeSystem()->DeclLinkToObject(decl.GetOpaqueDecl(), 
shared_from_this());
+}
 return decl;
 }
 


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

[Lldb-commits] [lldb] r266033 - Restore the lazy initialization of ScriptInterpreterPython, which was lost as part of the SystemLifetimeManager work

[Enrico Granata via lldb-commits]

Author: enrico
Date: Mon Apr 11 20:08:35 2016
New Revision: 266033

URL: http://llvm.org/viewvc/llvm-project?rev=266033&view=rev
Log:
Restore the lazy initialization of ScriptInterpreterPython, which was lost as 
part of the SystemLifetimeManager work


Modified:

lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h

Modified: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp?rev=266033&r1=266032&r2=266033&view=diff
==
--- 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
(original)
+++ 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
Mon Apr 11 20:08:35 2016
@@ -274,8 +274,8 @@ ScriptInterpreterPython::ScriptInterpret
 m_lock_count(0),
 m_command_thread_state(nullptr)
 {
-assert(g_initialized && "ScriptInterpreterPython created but 
InitializePrivate has not been called!");
-
+InitializePrivate();
+
 m_dictionary_name.append("_dict");
 StreamString run_string;
 run_string.Printf ("%s = dict()", m_dictionary_name.c_str());
@@ -330,8 +330,6 @@ ScriptInterpreterPython::Initialize()
 
 std::call_once(g_once_flag, []()
 {
-InitializePrivate();
-
 PluginManager::RegisterPlugin(GetPluginNameStatic(),
   GetPluginDescriptionStatic(),
   lldb::eScriptLanguagePython,
@@ -3097,7 +3095,9 @@ ScriptInterpreterPython::InitializeInter
 void
 ScriptInterpreterPython::InitializePrivate ()
 {
-assert(!g_initialized && "ScriptInterpreterPython::InitializePrivate() 
called more than once!");
+if (g_initialized)
+return;
+
 g_initialized = true;
 
 Timer scoped_timer (__PRETTY_FUNCTION__, __PRETTY_FUNCTION__);

Modified: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h?rev=266033&r1=266032&r2=266033&view=diff
==
--- 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h 
(original)
+++ 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h 
Mon Apr 11 20:08:35 2016
@@ -372,9 +372,6 @@ public:
 void ResetOutputFileHandle(FILE *new_fh) override;
 
 static void
-InitializePrivate ();
-
-static void
 InitializeInterpreter (SWIGInitCallback python_swig_init_callback,
SWIGBreakpointCallbackFunction 
swig_breakpoint_callback,
SWIGWatchpointCallbackFunction 
swig_watchpoint_callback,
@@ -507,6 +504,9 @@ public:
 };
 
 protected:
+static void
+InitializePrivate ();
+
 class SynchronicityHandler
 {
 private:


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

Re: [Lldb-commits] [lldb] r266033 - Restore the lazy initialization of ScriptInterpreterPython, which was lost as part of the SystemLifetimeManager work

[Zachary Turner via lldb-commits]

I have a feeling this breaks something, but I'm not sure what. I remember
specifically needing this for some reason.

Did you verify that the gtest suite as well as the dotest suite and the
interactive interpreter all still pass / work?
On Mon, Apr 11, 2016 at 6:14 PM Enrico Granata via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: enrico
> Date: Mon Apr 11 20:08:35 2016
> New Revision: 266033
>
> URL: http://llvm.org/viewvc/llvm-project?rev=266033&view=rev
> Log:
> Restore the lazy initialization of ScriptInterpreterPython, which was lost
> as part of the SystemLifetimeManager work
>
>
> Modified:
>
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
>
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
>
> Modified:
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp?rev=266033&r1=266032&r2=266033&view=diff
>
> ==
> ---
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
> (original)
> +++
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
> Mon Apr 11 20:08:35 2016
> @@ -274,8 +274,8 @@ ScriptInterpreterPython::ScriptInterpret
>  m_lock_count(0),
>  m_command_thread_state(nullptr)
>  {
> -assert(g_initialized && "ScriptInterpreterPython created but
> InitializePrivate has not been called!");
> -
> +InitializePrivate();
> +
>  m_dictionary_name.append("_dict");
>  StreamString run_string;
>  run_string.Printf ("%s = dict()", m_dictionary_name.c_str());
> @@ -330,8 +330,6 @@ ScriptInterpreterPython::Initialize()
>
>  std::call_once(g_once_flag, []()
>  {
> -InitializePrivate();
> -
>  PluginManager::RegisterPlugin(GetPluginNameStatic(),
>GetPluginDescriptionStatic(),
>lldb::eScriptLanguagePython,
> @@ -3097,7 +3095,9 @@ ScriptInterpreterPython::InitializeInter
>  void
>  ScriptInterpreterPython::InitializePrivate ()
>  {
> -assert(!g_initialized &&
> "ScriptInterpreterPython::InitializePrivate() called more than once!");
> +if (g_initialized)
> +return;
> +
>  g_initialized = true;
>
>  Timer scoped_timer (__PRETTY_FUNCTION__, __PRETTY_FUNCTION__);
>
> Modified:
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h?rev=266033&r1=266032&r2=266033&view=diff
>
> ==
> ---
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
> (original)
> +++
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
> Mon Apr 11 20:08:35 2016
> @@ -372,9 +372,6 @@ public:
>  void ResetOutputFileHandle(FILE *new_fh) override;
>
>  static void
> -InitializePrivate ();
> -
> -static void
>  InitializeInterpreter (SWIGInitCallback python_swig_init_callback,
> SWIGBreakpointCallbackFunction
> swig_breakpoint_callback,
> SWIGWatchpointCallbackFunction
> swig_watchpoint_callback,
> @@ -507,6 +504,9 @@ public:
>  };
>
>  protected:
> +static void
> +InitializePrivate ();
> +
>  class SynchronicityHandler
>  {
>  private:
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r266033 - Restore the lazy initialization of ScriptInterpreterPython, which was lost as part of the SystemLifetimeManager work

[Enrico Granata via lldb-commits]

> On Apr 11, 2016, at 6:28 PM, Zachary Turner  wrote:
> 
> I have a feeling this breaks something, but I'm not sure what. I remember 
> specifically needing this for some reason.
> 

If you manage to repro the breakage, let’s work on getting it fixed
I’d like to not have to initialize Python eagerly - most users will probably 
not touch anything Python during debugging, and I have seen a few spin dumps 
connected to the eager initialization during debugging startup

> Did you verify that the gtest suite

No - but I believe the bots run it, so I will probably get yelled at soon if I 
broke something

> as well as the dotest suite

Yes

> and the interactive interpreter all still pass / work?

Yes

> On Mon, Apr 11, 2016 at 6:14 PM Enrico Granata via lldb-commits 
> mailto:lldb-commits@lists.llvm.org>> wrote:
> Author: enrico
> Date: Mon Apr 11 20:08:35 2016
> New Revision: 266033
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=266033&view=rev 
> 
> Log:
> Restore the lazy initialization of ScriptInterpreterPython, which was lost as 
> part of the SystemLifetimeManager work
> 
> 
> Modified:
> 
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
> 
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
> 
> Modified: 
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp?rev=266033&r1=266032&r2=266033&view=diff
>  
> 
> ==
> --- 
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
>  (original)
> +++ 
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
>  Mon Apr 11 20:08:35 2016
> @@ -274,8 +274,8 @@ ScriptInterpreterPython::ScriptInterpret
>  m_lock_count(0),
>  m_command_thread_state(nullptr)
>  {
> -assert(g_initialized && "ScriptInterpreterPython created but 
> InitializePrivate has not been called!");
> -
> +InitializePrivate();
> +
>  m_dictionary_name.append("_dict");
>  StreamString run_string;
>  run_string.Printf ("%s = dict()", m_dictionary_name.c_str());
> @@ -330,8 +330,6 @@ ScriptInterpreterPython::Initialize()
> 
>  std::call_once(g_once_flag, []()
>  {
> -InitializePrivate();
> -
>  PluginManager::RegisterPlugin(GetPluginNameStatic(),
>GetPluginDescriptionStatic(),
>lldb::eScriptLanguagePython,
> @@ -3097,7 +3095,9 @@ ScriptInterpreterPython::InitializeInter
>  void
>  ScriptInterpreterPython::InitializePrivate ()
>  {
> -assert(!g_initialized && "ScriptInterpreterPython::InitializePrivate() 
> called more than once!");
> +if (g_initialized)
> +return;
> +
>  g_initialized = true;
> 
>  Timer scoped_timer (__PRETTY_FUNCTION__, __PRETTY_FUNCTION__);
> 
> Modified: 
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h?rev=266033&r1=266032&r2=266033&view=diff
>  
> 
> ==
> --- 
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h 
> (original)
> +++ 
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h 
> Mon Apr 11 20:08:35 2016
> @@ -372,9 +372,6 @@ public:
>  void ResetOutputFileHandle(FILE *new_fh) override;
> 
>  static void
> -InitializePrivate ();
> -
> -static void
>  InitializeInterpreter (SWIGInitCallback python_swig_init_callback,
> SWIGBreakpointCallbackFunction 
> swig_breakpoint_callback,
> SWIGWatchpointCallbackFunction 
> swig_watchpoint_callback,
> @@ -507,6 +504,9 @@ public:
>  };
> 
>  protected:
> +static void
> +InitializePrivate ();
> +
>  class SynchronicityHandler
>  {
>  private:
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits 
> 


Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

[Lldb-commits] [PATCH] D19004: Use the section sizes to determine symbols sizes in the Symtab instead of just using the following symbol's address

[Jason Molenda via lldb-commits]

jasonmolenda created this revision.
jasonmolenda added a reviewer: clayborg.
jasonmolenda added a subscriber: lldb-commits.
jasonmolenda set the repository for this revision to rL LLVM.

The Symtab has an array of symbol file addresses and sizes for 
address-to-symbol lookups, created in Symtab::InitAddressIndexes.  The Symtab 
has a vector of symbol (m_symbols) and a parallel vector of Range entries 
(m_file_addr_to_index - the index being an index into m_symbols).  Once the 
m_symbols have been filled in, it makes a pass over them and creates the 
m_file_addr_to_index entries.  Then it does additional passes to fill in the 
sizes of the Range entries based on the other symbol start addresses.

I'm working on a problem in an environment where the sections of a file are 
noncontiguous in memory - so we can have a gap of hundreds of megabytes between 
the sections, and the last symbol in the first section gets a 400MB size.  If 
the unwinder (or one of the fallback unwind methods) happens to come up with an 
address in that 400MB gap, lldb will try to disassemble that entire section, 
thinking it is a function.

Before this patch, InitAddressIndexes would create the m_file_addr_to_index 
array, then set sizes based on the next symbol, then use the last section's end 
address to set the last symbol(s) in the array.

In this patch, I'm using the smaller of the containing section end OR the next 
symbol's address to determine the symbol's size.  Looking up the section for 
each symbol would be expensive, so I make a local RangeVector with all of the 
section address/sizes before I loop over the entries.  RangeVector::Sort sorts 
by start address and then by size so we'll get the smallest containing section 
for a given lookup.

Repository:
  rL LLVM

http://reviews.llvm.org/D19004

Files:
  include/lldb/Core/RangeMap.h
  source/Symbol/Symtab.cpp

Index: source/Symbol/Symtab.cpp
===
--- source/Symbol/Symtab.cpp
+++ source/Symbol/Symtab.cpp
@@ -947,6 +947,33 @@
 return -1;
 }
 
+// Add all the section file start address & size to the RangeVector,
+// recusively adding any children sections.  
+static void
+AddSectionsToRangeMap (SectionList *sectlist, RangeVector §ion_ranges)
+{
+const int num_sections = sectlist->GetNumSections (0);
+for (int i = 0; i < num_sections; i++)
+{
+SectionSP sect_sp = sectlist->GetSectionAtIndex (i);
+if (sect_sp)
+{
+addr_t base_addr = sect_sp->GetFileAddress();
+size_t size = sect_sp->GetByteSize();
+RangeVector::Entry entry;
+entry.SetRangeBase (base_addr);
+entry.SetByteSize (size);
+section_ranges.Append (entry);
+
+SectionList &child_sectlist = sect_sp->GetChildren();
+			if (child_sectlist.GetNumSections (0) > 0)
+			{
+AddSectionsToRangeMap (&child_sectlist, section_ranges);
+}
+}
+}
+}
+
 void
 Symtab::InitAddressIndexes()
 {
@@ -972,37 +999,69 @@
 if (num_entries > 0)
 {
 m_file_addr_to_index.Sort();
-m_file_addr_to_index.CalculateSizesOfZeroByteSizeRanges();
-
-// Now our last symbols might not have had sizes because there
-// was no subsequent symbol to calculate the size from. If this is
-// the case, then calculate the size by capping it at the end of the
-// section in which the symbol resides
-for (int i = num_entries - 1; i >= 0; --i)
+
+// Create a RangeVector with the start & size of all the sections for
+// this objfile.  We'll need to check this for any FileRangeToIndexMap
+// entries with an uninitialized size, which could potentially be a
+// large number so reconstituting the weak pointer is busywork when it
+// is invariant information.
+SectionList *sectlist = m_objfile->GetSectionList();
+RangeVector section_ranges;
+if (sectlist)
 {
-const FileRangeToIndexMap::Entry &entry = m_file_addr_to_index.GetEntryRef(i);
-// As we iterate backwards, as soon as we find a symbol with a valid
-// byte size, we are done
-if (entry.GetByteSize() > 0)
-break;
+AddSectionsToRangeMap (sectlist, section_ranges);
+section_ranges.Sort();
+}
 
-// Cap the size to the end of the section in which the symbol resides
-SectionSP section_sp (m_objfile->GetSectionList()->FindSectionContainingFileAddress (entry.GetRangeBase()));
-if (section_sp)
+// Iterate through the FileRangeToIndexMap and fill in the size for any
+// entries that didn't already have a size from the Symbol (e.g. if we
+// have a plain linker symbol with an address only, in

[Lldb-commits] [lldb] r266042 - Process: fix the build with certain kernel versions

[Saleem Abdulrasool via lldb-commits]

Author: compnerd
Date: Tue Apr 12 00:40:51 2016
New Revision: 266042

URL: http://llvm.org/viewvc/llvm-project?rev=266042&view=rev
Log:
Process: fix the build with certain kernel versions

The structure definitions are not provided, but we perform a sizeof operation of
them which causes a build failure.  Include `asm/ptrace.h` to get the structure
definitions.

Modified:
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp

Modified: 
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp?rev=266042&r1=266041&r2=266042&view=diff
==
--- 
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp 
(original)
+++ 
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp 
Tue Apr 12 00:40:51 2016
@@ -32,6 +32,8 @@
 #include 
 // NT_PRSTATUS and NT_FPREGSET definition
 #include 
+// user_hwdebug_state definition
+#include 
 
 #define REG_CONTEXT_SIZE (GetGPRSize() + GetFPRSize())
 


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