[Lldb-commits] [PATCH] D15116: Fix for evaluating a function with an ambiguous symbol

[Ewan Crawford via lldb-commits]

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

I came across a bug for calling functions using expression evaluation, where 
the function name also matches a symbol from another compile unit.
The attached test case recreates it when compiled with gcc. Clang however 
doesn't seem to export a conflicting .rodata symbol so the bug doesn't appear.

Currently trying to call the function gives the following error in the test 
case.
   
```
 (lldb) expr overloaded_symbol(1)
 error: warning: got name from symbols: overloaded_symbol
 error: reference to 'overloaded_symbol' is ambiguous
 note: candidate found by name lookup is 'overloaded_symbol'
 note: candidate found by name lookup is 'overloaded_symbol'
 error: 1 errors parsing expression
```

This patch in the clang expression parser stops us turning the symbol into a 
global variable declaration if we've already found
a matching function. I'm not familiar with this code, so if there's a better 
way to fix this please let me know.

Repository:
  rL LLVM

http://reviews.llvm.org/D15116

Files:
  packages/Python/lldbsuite/test/expression_command/overloaded_symbol/Makefile
  
packages/Python/lldbsuite/test/expression_command/overloaded_symbol/TestCallSymbolConflict.py
  packages/Python/lldbsuite/test/expression_command/overloaded_symbol/main.cpp
  
packages/Python/lldbsuite/test/expression_command/overloaded_symbol/overload.cpp
  source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp

Index: source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
@@ -1576,7 +1576,7 @@
 } while (0);
 }
 
-if (target && !context.m_found.variable && !namespace_decl)
+if (target && !context.m_found.variable && 
!context.m_found.function && !context.m_found.function_with_type_info && 
!namespace_decl)
 {
 // We couldn't find a non-symbol variable for this.  Now we'll 
hunt for a generic
 // data symbol, and -- if it is found -- treat it as a 
variable.
Index: 
packages/Python/lldbsuite/test/expression_command/overloaded_symbol/overload.cpp
===
--- 
packages/Python/lldbsuite/test/expression_command/overloaded_symbol/overload.cpp
+++ 
packages/Python/lldbsuite/test/expression_command/overloaded_symbol/overload.cpp
@@ -0,0 +1,6 @@
+const int overloaded_symbol = 2;
+
+int return_global()
+{
+return overloaded_symbol;
+}
Index: 
packages/Python/lldbsuite/test/expression_command/overloaded_symbol/main.cpp
===
--- packages/Python/lldbsuite/test/expression_command/overloaded_symbol/main.cpp
+++ packages/Python/lldbsuite/test/expression_command/overloaded_symbol/main.cpp
@@ -0,0 +1,12 @@
+int return_global();
+
+int overloaded_symbol(int x)
+{
+return x + 1;
+}
+
+int main()
+{
+int my_local = return_global(); // break here
+return overloaded_symbol(my_local);
+}
Index: 
packages/Python/lldbsuite/test/expression_command/overloaded_symbol/TestCallSymbolConflict.py
===
--- 
packages/Python/lldbsuite/test/expression_command/overloaded_symbol/TestCallSymbolConflict.py
+++ 
packages/Python/lldbsuite/test/expression_command/overloaded_symbol/TestCallSymbolConflict.py
@@ -0,0 +1,36 @@
+"""
+Test calling function which has a name conflicting with a .rodata symbol
+"""
+
+from __future__ import print_function
+
+
+
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+class ExprCommandCallSymbolConfict(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+# Call super's setUp().
+TestBase.setUp(self)
+# Find the line number to break for main.c.
+self.line = line_number('main.cpp', '// break here')
+
+@expectedFlakeyDsym("llvm.org/pr20274")
+@expectedFailureWindows("llvm.org/pr24489: Name lookup not working 
correctly on Windows")
+def test(self):
+"""Test return value of call to function whose name conflicts with 
another symbol."""
+self.build()
+
+# Set breakpoint in main and run exe
+self.runCmd("file a.out", CURRENT_EXECUTABLE_SET)
+lldbutil.run_break_set_by_file_and_line (self, "main.cpp", self.line, 
num_expected_locations=-1, loc_exact=True)
+
+self.runCmd("run", RUN_SUCCEEDED)
+
+# Function semantics are simply to return the incremented integer 
parameter
+self.expect("expr overloaded_symbol(5)", substrs = ['$0 = 6'])
Index: 

[Lldb-commits] [lldb] r254430 - Revert "Fix race during process interruption"

[Pavel Labath via lldb-commits]

Author: labath
Date: Tue Dec  1 11:59:56 2015
New Revision: 254430

URL: http://llvm.org/viewvc/llvm-project?rev=254430=rev
Log:
Revert "Fix race during process interruption"

The android buildbot gets quite flaky after this change. I'm reverting it while 
I investigate.

Modified:
lldb/trunk/include/lldb/Target/Process.h

lldb/trunk/packages/Python/lldbsuite/test/expression_command/timeout/TestCallWithTimeout.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/attach_resume/TestAttachResume.py
lldb/trunk/source/Target/Process.cpp

Modified: lldb/trunk/include/lldb/Target/Process.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Process.h?rev=254430=254429=254430=diff
==
--- lldb/trunk/include/lldb/Target/Process.h (original)
+++ lldb/trunk/include/lldb/Target/Process.h Tue Dec  1 11:59:56 2015
@@ -1355,7 +1355,6 @@ public:
 
 Error
 ResumeSynchronous (Stream *stream);
-
 //--
 /// Halts a running process.
 ///
@@ -1368,15 +1367,12 @@ public:
 /// @param[in] clear_thread_plans
 /// If true, when the process stops, clear all thread plans.
 ///
-/// @param[in] use_run_lock
-/// Whether to release the run lock after the stop.
-///
 /// @return
 /// Returns an error object.  If the error is empty, the process is 
halted.
 /// otherwise the halt has failed.
 //--
 Error
-Halt (bool clear_thread_plans = false, bool use_run_lock = true);
+Halt (bool clear_thread_plans = false);
 
 //--
 /// Detaches from a running or stopped process.
@@ -1687,8 +1683,9 @@ public:
 /// DoHalt must produce one and only one stop StateChanged event if it 
actually
 /// stops the process.  If the stop happens through some natural event (for
 /// instance a SIGSTOP), then forwarding that event will do.  Otherwise, 
you must 
-/// generate the event manually. This function is called from the context 
of the
-/// private state thread.
+/// generate the event manually.  Note also, the private event thread is 
stopped when 
+/// DoHalt is run to prevent the events generated while halting to trigger
+/// other state changes before the halt is complete.
 ///
 /// @param[out] caused_stop
 /// If true, then this Halt caused the stop, otherwise, the 
@@ -2864,16 +2861,12 @@ public:
 // Returns the process state when it is stopped. If specified, event_sp_ptr
 // is set to the event which triggered the stop. If wait_always = false,
 // and the process is already stopped, this function returns immediately.
-// If the process is hijacked and use_run_lock is true (the default), then 
this
-// function releases the run lock after the stop. Setting use_run_lock to 
false
-// will avoid this behavior.
 lldb::StateType
 WaitForProcessToStop(const TimeValue *timeout,
  lldb::EventSP *event_sp_ptr = nullptr,
  bool wait_always = true,
  Listener *hijack_listener = nullptr,
- Stream *stream = nullptr,
- bool use_run_lock = true);
+ Stream *stream = nullptr);
 
 uint32_t
 GetIOHandlerID () const
@@ -3288,6 +3281,12 @@ protected:
 std::string m_exit_string;
 };
 
+bool 
+HijackPrivateProcessEvents (Listener *listener);
+
+void 
+RestorePrivateProcessEvents ();
+
 bool
 PrivateStateThreadIsValid () const
 {
@@ -3373,6 +3372,7 @@ protected:
 std::vector m_pre_resume_actions;
 ProcessRunLock  m_public_run_lock;
 ProcessRunLock  m_private_run_lock;
+Predicate m_currently_handling_event; // This predicate 
is set in HandlePrivateEvent while all its business is being done.
 ArchSpec::StopInfoOverrideCallbackType m_stop_info_override_callback;
 boolm_currently_handling_do_on_removals;
 boolm_resume_requested; // If 
m_currently_handling_event or m_currently_handling_do_on_removals are true, 
Resume will only request a resume, using this flag to check.
@@ -3436,9 +3436,6 @@ protected:
 void
 HandlePrivateEvent (lldb::EventSP _sp);
 
-Error
-HaltPrivate();
-
 lldb::StateType
 WaitForProcessStopPrivate (const TimeValue *timeout, lldb::EventSP 
_sp);
 

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/timeout/TestCallWithTimeout.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/timeout/TestCallWithTimeout.py?rev=254430=254429=254430=diff

Re: [Lldb-commits] [PATCH] D15067: Design building out of sources

[Eugene Zelenko via lldb-commits]

Eugene.Zelenko added a comment.

In http://reviews.llvm.org/D15067#299220, @labath wrote:

> In http://reviews.llvm.org/D15067#298902, @Eugene.Zelenko wrote:
>
> > But it's necessary to pass path from CMake command line argument to 
> > find_program after PATHS. Another problem if default OS location (if Clang 
> > installed and of old version) will be returned instead of build one.
>
>
> I don't know what would be the idiomatic cmake-fu to achieve that, but I'd 
> just pass the the full path to the llvm-config binary, including the name. 
> This way, we could also handle cases when the binary has a version suffix 
> (e.g., debian likes to ship the binary as llvm-config-3.x).


I think find_program() should be called if LLVM_CONFIG is empty or not exist.


Repository:
  rL LLVM

http://reviews.llvm.org/D15067



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

Re: [Lldb-commits] [PATCH] D11465: Fix "process load/unload" on android

[Greg Clayton via lldb-commits]

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

Looks fine.


http://reviews.llvm.org/D11465



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

Re: [Lldb-commits] Buildbot numbers for week of 11/22/2015 - 11/28/2015

[Tobias Grosser via lldb-commits]

On 12/01/2015 02:05 AM, David Blaikie wrote:



On Mon, Nov 30, 2015 at 5:00 PM, Galina Kistanova > wrote:

Hi David,

Thank you for the useful suggestions, I will work on these.

>I guess the entries with no entry in the failed column have zero failures?
Yes.

  perf-x86_64-penryn-O3-polly-before-vectorizer
| 31 | 31 |
  perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only
| 31 | 27 | 05:28:12

These /\ two builders failed most of the time, but they also only
ran a handful of times. I guess they're triggering off polly changes
only? I wonder if they should trigger off LLVM changes too, but I'm
not sure.

They build on llvm changes also, but they both build for quite a
long time. I think it's the reason why they do not build more.


Ah, OK - so the other suggestions might help demonstrate/understand that
behavior better.


These buildbots run performance tests, meaning they run the LNT test 
suite 10 times per run to get stable results. They are triggered on any 
LLVM/clang/Polly test but do not run more often just because we do not
have more hardware to run them more often. The relevant buildslave is 
constantly building something.



Tobias - any idea why these builders are /quite/ so slow & whether they
could be improved? With large blame lists that come from a small number
of slaves on a slow builder task it makes them hard to action. Are they
useful to you?


These bots do _not_ send out any emails, exactly for this reason. But 
yes, they are very useful to quickly get an idea of our current 
compile-time/run-time performance.


Thanks for you taking care of the buildbot noise. If my bots cause any 
issue for you, please let me know. Ensuring low noise is very important.


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

Re: [Lldb-commits] [PATCH] D15046: Fix for TestNoreturnUnwind.py on i386

[Jason Molenda via lldb-commits]

jasonmolenda added a comment.

Just to be clear - the change your proposing may be a good improvement for 
falling back to another unwind plan when the initial unwind plan fails.  But 
I'm curious why the initial unwind plan (assembly) failed here to begin with.  
I think lldb should have profiled this function correctly.


http://reviews.llvm.org/D15046



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

Re: [Lldb-commits] [PATCH] D15092: Fix hang in global static initialization

[Ewan Crawford via lldb-commits]

EwanCrawford added a comment.

Thanks for fixing this Adrian


Repository:
  rL LLVM

http://reviews.llvm.org/D15092



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

Re: [Lldb-commits] [PATCH] D15067: Design building out of sources

[Pavel Labath via lldb-commits]

labath added a comment.

In http://reviews.llvm.org/D15067#298902, @Eugene.Zelenko wrote:

> But it's necessary to pass path from CMake command line argument to 
> find_program after PATHS. Another problem if default OS location (if Clang 
> installed and of old version) will be returned instead of build one.


I don't know what would be the idiomatic cmake-fu to achieve that, but I'd just 
pass the the full path to the llvm-config binary, including the name. This way, 
we could also handle cases when the binary has a version suffix (e.g., debian 
likes to ship the binary as llvm-config-3.x).


Repository:
  rL LLVM

http://reviews.llvm.org/D15067



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

Re: [Lldb-commits] [PATCH] D15046: Fix for TestNoreturnUnwind.py on i386

[Ravitheja Addepally via lldb-commits]

ravitheja added a comment.

Hi Jason,

  Ok let me explain the scenario here, the application i.e the test function 
tries to abort which eventually ends up in a function present in the vdso, on 
the way the call flow goes through some functions in libc. Now the backtrace is 
done from inside of the function in the vdso, which was successful in the case 
of gcc and unsuccessful for clang. Before I tell you my findings, I would 
mention that the vdso is mapped by the kernel in to the inferiors memory and 
would be the same for clang or gcc. Now I found that the ebp register was not 
touched by the functions in the libc and the assembly unwind plan was used for 
the vdso for the first frame. This was successful for gcc because gcc emitted 
the prologue for the main function whereas clang does not. 

Here is the log without my patch -

(lldb) log enable lldb unwind
(lldb) run
Process 99000 launched: 
'/nfs/site/disks/idb_team/raddepal/LLDB/llvm/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/unwind/noreturn/a.out'
 (i386)
th1/fr0 with pc value of 0x8048350, symbol name is ''
(i386) 
/nfs/site/disks/idb_team/raddepal/LLDB/llvm/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/unwind/noreturn/a.out:
 Reading EH frame info
th1/fr0 0x08048350: CFA=esp +4 => esp=CFA+0 eip=[CFA-4]

th1/fr0 CFA is 0xd4d4: Register esp (7) contents are 0xd4d0, offset is 4
th1/fr0 initialized frame current pc is 0x8048350 cfa is 0xd4d4 using 
assembly insn profiling UnwindPlan
th1/fr0 supplying caller's saved eip (8)'s location using assembly insn 
profiling UnwindPlan
th1/fr0 supplying caller's register eip (8) from the stack, saved at CFA plus 
offset -4 [saved at 0xd4d0]
 th1/fr1 pc = 0x1
th1/fr0 supplying caller's register ebp (6) from the live RegisterContext at 
frame 0
 th1/fr1 fp = 0x0
th1/fr0 supplying caller's saved esp (7)'s location using assembly insn 
profiling UnwindPlan
th1/fr0 supplying caller's register esp (7), value is CFA plus offset 0 [value 
is 0xd4d4]
 th1/fr1 sp = 0xd4d4
 th1/fr1 this frame has a pc of 0x0
th1/fr0 supplying caller's saved eip (8)'s location, cached
th1/fr0 Got an invalid CFA register value - reg ebp (6), value 0x0
th1/fr0 failed to get cfa with fallback unwindplan
 Frame 1 invalid RegisterContext for this frame, stopping stack walk
th1 Unwind of this thread is complete.
th1/fr0 with pc value of 0xf7fd9d80, symbol name is '__kernel_vsyscall'
(i386) [vdso](0xf7fd9000): Reading EH frame info
th1/fr0 0xf7fd9d75: CFA=ebp+16 => ebp=[CFA-16] esp=CFA+0 eip=[CFA-4]

th1/fr0 Got an invalid CFA register value - reg ebp (6), value 0x0
th1/fr0 could not read CFA register for this frame.
th1 Unwind of this thread is complete.
Process 99000 stopped

- thread #1: tid = 99000, 0xf7fd9d80 [vdso]`__kernel_vsyscall + 16, name = 
'a.out', stop reason = signal SIGABRT frame #0: 0xf7fd9d80 
[vdso]`__kernel_vsyscall + 16

[vdso]`__kernel_vsyscall:
->  0xf7fd9d80 <+16>: popl   %ebp

  0xf7fd9d81 <+17>: popl   %edx
  0xf7fd9d82 <+18>: popl   %ecx
  0xf7fd9d83 <+19>: retl   

(lldb) disassemble
[vdso]`__kernel_vsyscall:

  0xf7fd9d70 <+0>:  pushl  %ecx
  0xf7fd9d71 <+1>:  pushl  %edx
  0xf7fd9d72 <+2>:  pushl  %ebp
  0xf7fd9d73 <+3>:  movl   %esp, %ebp
  0xf7fd9d75 <+5>:  sysenter 
  0xf7fd9d77 <+7>:  nop
  0xf7fd9d78 <+8>:  nop
  0xf7fd9d79 <+9>:  nop
  0xf7fd9d7a <+10>: nop
  0xf7fd9d7b <+11>: nop
  0xf7fd9d7c <+12>: nop
  0xf7fd9d7d <+13>: nop
  0xf7fd9d7e <+14>: int$0x80

->  0xf7fd9d80 <+16>: popl   %ebp

  0xf7fd9d81 <+17>: popl   %edx
  0xf7fd9d82 <+18>: popl   %ecx
  0xf7fd9d83 <+19>: retl   

After the patch ->

(lldb) log enable lldb unwind
(lldb) run
Process 99000 launched: 
'/nfs/site/disks/idb_team/raddepal/LLDB/llvm/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/unwind/noreturn/a.out'
 (i386)
th1/fr0 with pc value of 0x8048350, symbol name is ''
(i386) 
/nfs/site/disks/idb_team/raddepal/LLDB/llvm/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/unwind/noreturn/a.out:
 Reading EH frame info
th1/fr0 0x08048350: CFA=esp +4 => esp=CFA+0 eip=[CFA-4]

th1/fr0 CFA is 0xd4d4: Register esp (7) contents are 0xd4d0, offset is 4
th1/fr0 initialized frame current pc is 0x8048350 cfa is 0xd4d4 using 
assembly insn profiling UnwindPlan
th1/fr0 supplying caller's saved eip (8)'s location using assembly insn 
profiling UnwindPlan
th1/fr0 supplying caller's register eip (8) from the stack, saved at CFA plus 
offset -4 [saved at 0xd4d0]
 th1/fr1 pc = 0x1
th1/fr0 supplying caller's register ebp (6) from the live RegisterContext at 
frame 0
 th1/fr1 fp = 0x0
th1/fr0 supplying caller's saved esp (7)'s location using assembly insn 
profiling UnwindPlan
th1/fr0 supplying caller's register esp (7), value is CFA plus offset 0 [value 
is 0xd4d4]
 th1/fr1 sp = 0xd4d4
 th1/fr1 this frame has a pc of 0x0
th1/fr0 supplying caller's saved eip (8)'s location, cached

Re: [Lldb-commits] [PATCH] D15042: PTRACE ABI to read FXSAVE area for 32-bit inferior

[Abhishek via lldb-commits]

abhishek.aggarwal added a comment.

Hello Greg

Is there anyone else , except the reviewers already included for the patch, I 
should put as the reviewer for this patch ?


http://reviews.llvm.org/D15042



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

Re: [Lldb-commits] [PATCH] D15042: PTRACE ABI to read FXSAVE area for 32-bit inferior

[Abhishek via lldb-commits]

abhishek.aggarwal added a comment.

Hi Pavel and Tamas

I enabled logs in case ptrace API fails to read FXSAVE/XSAVE area. This will 
serve as an indicator to find the reason of failure if register read fails.


http://reviews.llvm.org/D15042



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

Re: [Lldb-commits] [PATCH] D15042: PTRACE ABI to read FXSAVE area for 32-bit inferior

[Abhishek via lldb-commits]

abhishek.aggarwal updated this revision to Diff 41489.
abhishek.aggarwal added a comment.

Added Loggings

An indication through logs in case ptrace API fails
 to read FXSAVE/XSAVE area.


http://reviews.llvm.org/D15042

Files:
  packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
  source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp

Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
@@ -327,6 +327,9 @@
 #ifndef NT_X86_XSTATE
 #define NT_X86_XSTATE 0x202
 #endif
+#ifndef NT_PRXFPREG
+#define NT_PRXFPREG 0x46e62b7f
+#endif
 
 NativeRegisterContextLinux*
 NativeRegisterContextLinux::CreateHostNativeRegisterContextLinux(const ArchSpec& target_arch,
@@ -832,6 +835,7 @@
 NativeRegisterContextLinux_x86_64::FPRType
 NativeRegisterContextLinux_x86_64::GetFPRType () const
 {
+Log *log(GetLogIfAllCategoriesSet(LIBLLDB_LOG_PROCESS));
 if (m_fpr_type == eFPRTypeNotValid)
 {
 // TODO: Use assembly to call cpuid on the inferior and query ebx or ecx.
@@ -842,9 +846,15 @@
 {
 // Fall back to general floating point with no AVX support.
 m_fpr_type = eFPRTypeFXSAVE;
+
+// Check if FXSAVE area can be read.
+if (const_cast(this)->ReadFPR().Fail())
+{
+if (log)
+log->Printf("NativeRegisterContextLinux_x86_64::%s ptrace APIs failed to read XSAVE/FXSAVE area", __FUNCTION__);
+}
 }
 }
-
 return m_fpr_type;
 }
 
@@ -868,10 +878,24 @@
 NativeRegisterContextLinux_x86_64::WriteFPR()
 {
 const FPRType fpr_type = GetFPRType ();
+const lldb_private::ArchSpec& target_arch = GetRegisterInfoInterface().GetTargetArchitecture();
 switch (fpr_type)
 {
 case FPRType::eFPRTypeFXSAVE:
-return NativeRegisterContextLinux::WriteFPR();
+// For 32-bit inferiors on x86_32/x86_64 architectures,
+// FXSAVE area can be written using PTRACE_SETREGSET ptrace api
+// For 64-bit inferiors on x86_64 architectures,
+// FXSAVE area can be written using PTRACE_SETFPREGS ptrace api
+switch (target_arch.GetMachine ())
+{
+case llvm::Triple::x86:
+return WriteRegisterSet(_iovec, sizeof(m_fpr.xstate.xsave), NT_PRXFPREG);
+case llvm::Triple::x86_64:
+return NativeRegisterContextLinux::WriteFPR();
+default:
+assert(false && "Unhandled target architecture.");
+break;
+}
 case FPRType::eFPRTypeXSAVE:
 return WriteRegisterSet(_iovec, sizeof(m_fpr.xstate.xsave), NT_X86_XSTATE);
 default:
@@ -980,10 +1004,24 @@
 NativeRegisterContextLinux_x86_64::ReadFPR ()
 {
 const FPRType fpr_type = GetFPRType ();
+const lldb_private::ArchSpec& target_arch = GetRegisterInfoInterface().GetTargetArchitecture();
 switch (fpr_type)
 {
 case FPRType::eFPRTypeFXSAVE:
-return NativeRegisterContextLinux::ReadFPR();
+// For 32-bit inferiors on x86_32/x86_64 architectures,
+// FXSAVE area can be read using PTRACE_GETREGSET ptrace api
+// For 64-bit inferiors on x86_64 architectures,
+// FXSAVE area can be read using PTRACE_GETFPREGS ptrace api
+switch (target_arch.GetMachine ())
+{
+case llvm::Triple::x86:
+return ReadRegisterSet(_iovec, sizeof(m_fpr.xstate.xsave), NT_PRXFPREG);
+case llvm::Triple::x86_64:
+return NativeRegisterContextLinux::ReadFPR();
+default:
+assert(false && "Unhandled target architecture.");
+break;
+}
 case FPRType::eFPRTypeXSAVE:
 return ReadRegisterSet(_iovec, sizeof(m_fpr.xstate.xsave), NT_X86_XSTATE);
 default:
Index: packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
===
--- packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
+++ packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
@@ -16,7 +16,7 @@
 
 mydir = TestBase.compute_mydir(__file__)
 
-@expectedFailurei386
+@expectedFailureAll(oslist=["macosx","freebsd"], archs=["i386"])
 @expectedFailureWindows("llvm.org/pr24778")
 @add_test_categories(['pyapi'])
 def test_with_python(self):
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D11465: Fix "process load/unload" on android

[Tamas Berghammer via lldb-commits]

tberghammer updated this revision to Diff 41491.

http://reviews.llvm.org/D11465

Files:
  include/lldb/Target/Platform.h
  include/lldb/Target/Process.h
  packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py
  source/API/SBProcess.cpp
  source/Commands/CommandObjectProcess.cpp
  source/Plugins/Platform/Android/PlatformAndroid.cpp
  source/Plugins/Platform/Android/PlatformAndroid.h
  source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
  source/Plugins/Platform/POSIX/PlatformPOSIX.h
  source/Target/Platform.cpp
  source/Target/Process.cpp

Index: source/Target/Process.cpp
===
--- source/Target/Process.cpp
+++ source/Target/Process.cpp
@@ -1885,223 +1885,6 @@
 return LLDB_INVALID_ADDRESS;
 }
 
-//--
-// LoadImage
-//
-// This function provides a default implementation that works for most
-// unix variants. Any Process subclasses that need to do shared library
-// loading differently should override LoadImage and UnloadImage and
-// do what is needed.
-//--
-uint32_t
-Process::LoadImage (const FileSpec _spec, Error )
-{
-if (m_finalizing)
-{
-error.SetErrorString("process is tearing itself down");
-return LLDB_INVALID_IMAGE_TOKEN;
-}
-
-char path[PATH_MAX];
-image_spec.GetPath(path, sizeof(path));
-
-DynamicLoader *loader = GetDynamicLoader();
-if (loader)
-{
-error = loader->CanLoadImage();
-if (error.Fail())
-return LLDB_INVALID_IMAGE_TOKEN;
-}
-
-if (error.Success())
-{
-ThreadSP thread_sp(GetThreadList ().GetSelectedThread());
-
-if (thread_sp)
-{
-StackFrameSP frame_sp (thread_sp->GetStackFrameAtIndex (0));
-
-if (frame_sp)
-{
-ExecutionContext exe_ctx;
-frame_sp->CalculateExecutionContext (exe_ctx);
-EvaluateExpressionOptions expr_options;
-expr_options.SetUnwindOnError(true);
-expr_options.SetIgnoreBreakpoints(true);
-expr_options.SetExecutionPolicy(eExecutionPolicyAlways);
-expr_options.SetResultIsInternal(true);
-expr_options.SetLanguage(eLanguageTypeC_plus_plus);
-
-StreamString expr;
-expr.Printf(R"(
-   struct __lldb_dlopen_result { void *image_ptr; const char *error_str; } the_result;
-   the_result.image_ptr = dlopen ("%s", 2);
-   if (the_result.image_ptr == (void *) 0x0)
-   {
-   the_result.error_str = dlerror();
-   }
-   else
-   {
-   the_result.error_str = (const char *) 0x0;
-   }
-   the_result;
-  )",
-  path);
-const char *prefix = R"(
-extern "C" void* dlopen (const char *path, int mode);
-extern "C" const char *dlerror (void);
-)";
-lldb::ValueObjectSP result_valobj_sp;
-Error expr_error;
-UserExpression::Evaluate (exe_ctx,
-  expr_options,
-  expr.GetData(),
-  prefix,
-  result_valobj_sp,
-  expr_error);
-if (expr_error.Success())
-{
-error = result_valobj_sp->GetError();
-if (error.Success())
-{
-Scalar scalar;
-ValueObjectSP image_ptr_sp = result_valobj_sp->GetChildAtIndex(0, true);
-if (image_ptr_sp && image_ptr_sp->ResolveValue (scalar))
-{
-addr_t image_ptr = scalar.ULongLong(LLDB_INVALID_ADDRESS);
-if (image_ptr != 0 && image_ptr != LLDB_INVALID_ADDRESS)
-{
-uint32_t image_token = m_image_tokens.size();
-m_image_tokens.push_back (image_ptr);
-return image_token;
-}
-else if (image_ptr == 0)
-{
-ValueObjectSP error_str_sp = result_valobj_sp->GetChildAtIndex(1, true);
-   

Re: [Lldb-commits] [PATCH] D11465: Fix "process load/unload" on android

[Tamas Berghammer via lldb-commits]

tberghammer added inline comments.


Comment at: test/functionalities/load_unload/TestLoadUnload.py:201-204
@@ -205,7 +200,6 @@
 
-if lldb.remote_platform:
-dylibName = os.path.join(shlib_dir, 'libloadunload_a.so')
-elif self.platformIsDarwin():
+if self.platformIsDarwin():
 dylibName = 'libloadunload_a.dylib'
 else:
 dylibName = 'libloadunload_a.so'
+

clayborg wrote:
> It would be great to add something to lldb::SBPlatform and 
> lldb_private::Platform that allows us to get the shared library extension 
> from the platform:
> 
> ```
> class SBPlatform
> {
> const char *
> GetSharedLibraryExtension();
> };
> ```
> 
> Then this code can become:
> 
> ```
> dylibName = "libloadunload" + platform.GetSharedLibraryExtension()
> 
> 
It is a fairly unrelated change. Will create a separate CL for it


Comment at: test/functionalities/load_unload/TestLoadUnload.py:206-209
@@ +205,6 @@
+
+if lldb.remote_platform:
+dylibPath = os.path.join(shlib_dir, 'libloadunload_a.so')
+else:
+dylibPath = dylibName
+

clayborg wrote:
> This code should be:
> 
> ```
> if lldb.remote_platform:
> dylibPath = os.path.join(shlib_dir, dylibName)
> else:
> dylibPath = dylibName
> ```
Done


http://reviews.llvm.org/D11465



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

Re: [Lldb-commits] [PATCH] D15042: PTRACE ABI to read FXSAVE area for 32-bit inferior

[Pavel Labath via lldb-commits]

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

Looks good.


http://reviews.llvm.org/D15042



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

Re: [Lldb-commits] [PATCH] D11465: Fix "process load/unload" on android

[Tamas Berghammer via lldb-commits]

tberghammer updated the summary for this revision.
tberghammer updated this revision to Diff 41490.
tberghammer added a comment.
Herald added a subscriber: emaste.

Address review comments


http://reviews.llvm.org/D11465

Files:
  include/lldb/Target/Platform.h
  include/lldb/Target/Process.h
  packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py
  source/API/SBProcess.cpp
  source/Commands/CommandObjectProcess.cpp
  source/Plugins/Platform/Android/PlatformAndroid.cpp
  source/Plugins/Platform/Android/PlatformAndroid.h
  source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
  source/Plugins/Platform/POSIX/PlatformPOSIX.h
  source/Target/Platform.cpp
  source/Target/Process.cpp

Index: source/Target/Process.cpp
===
--- source/Target/Process.cpp
+++ source/Target/Process.cpp
@@ -1885,223 +1885,6 @@
 return LLDB_INVALID_ADDRESS;
 }
 
-//--
-// LoadImage
-//
-// This function provides a default implementation that works for most
-// unix variants. Any Process subclasses that need to do shared library
-// loading differently should override LoadImage and UnloadImage and
-// do what is needed.
-//--
-uint32_t
-Process::LoadImage (const FileSpec _spec, Error )
-{
-if (m_finalizing)
-{
-error.SetErrorString("process is tearing itself down");
-return LLDB_INVALID_IMAGE_TOKEN;
-}
-
-char path[PATH_MAX];
-image_spec.GetPath(path, sizeof(path));
-
-DynamicLoader *loader = GetDynamicLoader();
-if (loader)
-{
-error = loader->CanLoadImage();
-if (error.Fail())
-return LLDB_INVALID_IMAGE_TOKEN;
-}
-
-if (error.Success())
-{
-ThreadSP thread_sp(GetThreadList ().GetSelectedThread());
-
-if (thread_sp)
-{
-StackFrameSP frame_sp (thread_sp->GetStackFrameAtIndex (0));
-
-if (frame_sp)
-{
-ExecutionContext exe_ctx;
-frame_sp->CalculateExecutionContext (exe_ctx);
-EvaluateExpressionOptions expr_options;
-expr_options.SetUnwindOnError(true);
-expr_options.SetIgnoreBreakpoints(true);
-expr_options.SetExecutionPolicy(eExecutionPolicyAlways);
-expr_options.SetResultIsInternal(true);
-expr_options.SetLanguage(eLanguageTypeC_plus_plus);
-
-StreamString expr;
-expr.Printf(R"(
-   struct __lldb_dlopen_result { void *image_ptr; const char *error_str; } the_result;
-   the_result.image_ptr = dlopen ("%s", 2);
-   if (the_result.image_ptr == (void *) 0x0)
-   {
-   the_result.error_str = dlerror();
-   }
-   else
-   {
-   the_result.error_str = (const char *) 0x0;
-   }
-   the_result;
-  )",
-  path);
-const char *prefix = R"(
-extern "C" void* dlopen (const char *path, int mode);
-extern "C" const char *dlerror (void);
-)";
-lldb::ValueObjectSP result_valobj_sp;
-Error expr_error;
-UserExpression::Evaluate (exe_ctx,
-  expr_options,
-  expr.GetData(),
-  prefix,
-  result_valobj_sp,
-  expr_error);
-if (expr_error.Success())
-{
-error = result_valobj_sp->GetError();
-if (error.Success())
-{
-Scalar scalar;
-ValueObjectSP image_ptr_sp = result_valobj_sp->GetChildAtIndex(0, true);
-if (image_ptr_sp && image_ptr_sp->ResolveValue (scalar))
-{
-addr_t image_ptr = scalar.ULongLong(LLDB_INVALID_ADDRESS);
-if (image_ptr != 0 && image_ptr != LLDB_INVALID_ADDRESS)
-{
-uint32_t image_token = m_image_tokens.size();
-m_image_tokens.push_back (image_ptr);
-return image_token;
-}
-else if (image_ptr == 0)
-   

[Lldb-commits] [lldb] r254403 - Fix race during process interruption

[Pavel Labath via lldb-commits]

Author: labath
Date: Tue Dec  1 05:28:47 2015
New Revision: 254403

URL: http://llvm.org/viewvc/llvm-project?rev=254403=rev
Log:
Fix race during process interruption

Summary:
The following situation was occuring in TestAttachResume:
- we did a "continue" from a breakpoint (which involves a private start-stop to 
step over the
  breakpoint)
- after receiving the stop-reply from the step-over, we issue a "detach" (which 
requires a
  process interrupt)
- at this moment, the public state is "running", private state is 
"about-to-be-stopped" (the
  stopped event was broadcast, but it was not received yet)
- StopForDestroyOrDetach (public thread) notes the public state is running, 
sends an interrupt
  request to the private thread
- private thread gets the eBroadcastBitInterrupt (before the eStateStopped 
message), and asks the
  process plugin to stop (via Halt())
- process plugin says it has nothing to do as the process is already stopped
- private thread shrugs and carries on. receives the stop event, restores the 
breakpoint and
  resumes the process.
- after a while, the public thread times out and says it failed to stop the 
process

This patch does the following:
- splits Halt() into two functions, private and public, their usage depends on 
the context
  - public Halt(): sends eBroadcastBitInterrupt to the private thread and waits 
for the Stop
event
  - HaltPrivate(): asks the plugin to stop and makes a note that the halt was 
requested. When the
next stop event comes it sets the interrupt flag on it.
- removes HijackPrivateProcessEvents(), as the only user (old Halt()) has gone 
away
- removes the m_currently_handling_event hack, as the new Halt() does not need 
it
- adds a use_run_lock parameter to public Halt() and WaitForProcessToStop(). 
This was needed
  because RunThreadPlan uses Halt() while holding the run lock and we don't 
want Halt() to take
  it away from him.

Reviewers: clayborg, jingham

Subscribers: lldb-commits

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

Modified:
lldb/trunk/include/lldb/Target/Process.h

lldb/trunk/packages/Python/lldbsuite/test/expression_command/timeout/TestCallWithTimeout.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/attach_resume/TestAttachResume.py
lldb/trunk/source/Target/Process.cpp

Modified: lldb/trunk/include/lldb/Target/Process.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Process.h?rev=254403=254402=254403=diff
==
--- lldb/trunk/include/lldb/Target/Process.h (original)
+++ lldb/trunk/include/lldb/Target/Process.h Tue Dec  1 05:28:47 2015
@@ -1355,6 +1355,7 @@ public:
 
 Error
 ResumeSynchronous (Stream *stream);
+
 //--
 /// Halts a running process.
 ///
@@ -1367,12 +1368,15 @@ public:
 /// @param[in] clear_thread_plans
 /// If true, when the process stops, clear all thread plans.
 ///
+/// @param[in] use_run_lock
+/// Whether to release the run lock after the stop.
+///
 /// @return
 /// Returns an error object.  If the error is empty, the process is 
halted.
 /// otherwise the halt has failed.
 //--
 Error
-Halt (bool clear_thread_plans = false);
+Halt (bool clear_thread_plans = false, bool use_run_lock = true);
 
 //--
 /// Detaches from a running or stopped process.
@@ -1683,9 +1687,8 @@ public:
 /// DoHalt must produce one and only one stop StateChanged event if it 
actually
 /// stops the process.  If the stop happens through some natural event (for
 /// instance a SIGSTOP), then forwarding that event will do.  Otherwise, 
you must 
-/// generate the event manually.  Note also, the private event thread is 
stopped when 
-/// DoHalt is run to prevent the events generated while halting to trigger
-/// other state changes before the halt is complete.
+/// generate the event manually. This function is called from the context 
of the
+/// private state thread.
 ///
 /// @param[out] caused_stop
 /// If true, then this Halt caused the stop, otherwise, the 
@@ -2861,12 +2864,16 @@ public:
 // Returns the process state when it is stopped. If specified, event_sp_ptr
 // is set to the event which triggered the stop. If wait_always = false,
 // and the process is already stopped, this function returns immediately.
+// If the process is hijacked and use_run_lock is true (the default), then 
this
+// function releases the run lock after the stop. Setting use_run_lock to 
false
+// will avoid this behavior.
 lldb::StateType
 WaitForProcessToStop(const TimeValue *timeout,
  lldb::EventSP *event_sp_ptr = nullptr,

Re: [Lldb-commits] [PATCH] D14989: Fix race during process interruption

[Pavel Labath via lldb-commits]

This revision was automatically updated to reflect the committed changes.
labath marked 3 inline comments as done.
Closed by commit rL254403: Fix race during process interruption (authored by 
labath).

Changed prior to commit:
  http://reviews.llvm.org/D14989?vs=41215=41482#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D14989

Files:
  lldb/trunk/include/lldb/Target/Process.h
  
lldb/trunk/packages/Python/lldbsuite/test/expression_command/timeout/TestCallWithTimeout.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/attach_resume/TestAttachResume.py
  lldb/trunk/source/Target/Process.cpp

Index: lldb/trunk/packages/Python/lldbsuite/test/expression_command/timeout/TestCallWithTimeout.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/expression_command/timeout/TestCallWithTimeout.py
+++ lldb/trunk/packages/Python/lldbsuite/test/expression_command/timeout/TestCallWithTimeout.py
@@ -57,15 +57,15 @@
 
 frame = thread.GetFrameAtIndex(0)
 
-value = frame.EvaluateExpression ("wait_a_while (5)", options)
+value = frame.EvaluateExpression ("wait_a_while (20)", options)
 self.assertTrue (value.IsValid())
 self.assertFalse (value.GetError().Success())
 
 # Now do the same thing with the command line command, and make sure it works too.
 interp = self.dbg.GetCommandInterpreter()
 
 result = lldb.SBCommandReturnObject()
-return_value = interp.HandleCommand ("expr -t 100 -u true -- wait_a_while(5)", result)
+return_value = interp.HandleCommand ("expr -t 100 -u true -- wait_a_while(20)", result)
 self.assertTrue (return_value == lldb.eReturnStatusFailed)
 
 # Okay, now do it again with long enough time outs:
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/attach_resume/TestAttachResume.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/attach_resume/TestAttachResume.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/attach_resume/TestAttachResume.py
@@ -20,7 +20,6 @@
 @skipIfRemote
 @expectedFailureFreeBSD('llvm.org/pr19310')
 @expectedFailureWindows("llvm.org/pr24778")
-@expectedFlakeyLinux('llvm.org/pr19310')
 def test_attach_continue_interrupt_detach(self):
 """Test attach/continue/interrupt/detach"""
 self.build()
@@ -52,6 +51,9 @@
 self.runCmd("process interrupt")
 lldbutil.expect_state_changes(self, listener, [lldb.eStateStopped])
 
+# Second interrupt should have no effect.
+self.expect("process interrupt", patterns=["Process is not running"], error=True)
+
 # check that this breakpoint is auto-cleared on detach (r204752)
 self.runCmd("br set -f main.cpp -l %u" % (line_number('main.cpp', '// Set breakpoint here')))
 
Index: lldb/trunk/source/Target/Process.cpp
===
--- lldb/trunk/source/Target/Process.cpp
+++ lldb/trunk/source/Target/Process.cpp
@@ -759,7 +759,6 @@
 m_next_event_action_ap(),
 m_public_run_lock (),
 m_private_run_lock (),
-m_currently_handling_event(false),
 m_stop_info_override_callback (NULL),
 m_finalizing (false),
 m_finalize_called (false),
@@ -992,7 +991,8 @@
EventSP *event_sp_ptr,
bool wait_always,
Listener *hijack_listener,
-   Stream *stream)
+   Stream *stream,
+   bool use_run_lock)
 {
 // We can't just wait for a "stopped" event, because the stopped event may have restarted the target.
 // We have to actually check each event, and in the case of a stopped event check the restarted flag
@@ -1019,7 +1019,7 @@
 __FUNCTION__);
 // We need to toggle the run lock as this won't get done in
 // SetPublicState() if the process is hijacked.
-if (hijack_listener)
+if (hijack_listener && use_run_lock)
 m_public_run_lock.SetStopped();
 return state;
 }
@@ -1042,7 +1042,7 @@
 case eStateUnloaded:
 // We need to toggle the run lock as this won't get done in
 // SetPublicState() if the process is hijacked.
-if (hijack_listener)
+if (hijack_listener && use_run_lock)
 m_public_run_lock.SetStopped();
 return state;
 case eStateStopped:
@@ -1052,7 +1052,7 @@
 {
 // We need to toggle the run lock as this won't get done in
 // SetPublicState() if the process is hijacked.
-if (hijack_listener)
+if (hijack_listener && use_run_lock)
 m_public_run_lock.SetStopped();
  

[Lldb-commits] [PATCH] D15106: [LLDB][MIPS] fix watchpoint searched on client side for same masked variables

[Mohit Bhakkad via lldb-commits]

mohit.bhakkad created this revision.
mohit.bhakkad added a reviewer: clayborg.
mohit.bhakkad added subscribers: jaydeep, bhushan, nitesh.jain, sagar, 
lldb-commits.
mohit.bhakkad set the repository for this revision to rL LLVM.

rL249837 doesn't solves all the issues with MIPS false positives, some of the 
cases are not working.
so need to replace it with this logic.

Repository:
  rL LLVM

http://reviews.llvm.org/D15106

Files:
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -2110,9 +2110,12 @@
 watch_id_t watch_id = LLDB_INVALID_WATCH_ID;
 if (wp_addr != LLDB_INVALID_ADDRESS)
 {
-if (wp_hit_addr != LLDB_INVALID_ADDRESS)
-wp_addr = wp_hit_addr;
-WatchpointSP wp_sp = 
GetTarget().GetWatchpointList().FindByAddress(wp_addr);
+WatchpointSP wp_sp;
+ArchSpec::Core core = 
GetTarget().GetArchitecture().GetCore();
+if (core >= ArchSpec::kCore_mips_first && core 
<= ArchSpec::kCore_mips_last)
+wp_sp = 
GetTarget().GetWatchpointList().FindByAddress(wp_hit_addr);
+if (!wp_sp)
+wp_sp = 
GetTarget().GetWatchpointList().FindByAddress(wp_addr);
 if (wp_sp)
 {
 wp_sp->SetHardwareIndex(wp_index);


Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -2110,9 +2110,12 @@
 watch_id_t watch_id = LLDB_INVALID_WATCH_ID;
 if (wp_addr != LLDB_INVALID_ADDRESS)
 {
-if (wp_hit_addr != LLDB_INVALID_ADDRESS)
-wp_addr = wp_hit_addr;
-WatchpointSP wp_sp = GetTarget().GetWatchpointList().FindByAddress(wp_addr);
+WatchpointSP wp_sp;
+ArchSpec::Core core = GetTarget().GetArchitecture().GetCore();
+if (core >= ArchSpec::kCore_mips_first && core <= ArchSpec::kCore_mips_last)
+wp_sp = GetTarget().GetWatchpointList().FindByAddress(wp_hit_addr);
+if (!wp_sp)
+wp_sp = GetTarget().GetWatchpointList().FindByAddress(wp_addr);
 if (wp_sp)
 {
 wp_sp->SetHardwareIndex(wp_index);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D15042: PTRACE ABI to read FXSAVE area for 32-bit inferior

[Tamas Berghammer via lldb-commits]

tberghammer accepted this revision.
tberghammer added a reviewer: tberghammer.
tberghammer added a comment.

Looks good, and as it only effects Linux you can commit it just based on the 
review from Pavel


http://reviews.llvm.org/D15042



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

Re: [Lldb-commits] [PATCH] D15042: PTRACE ABI to read FXSAVE area for 32-bit inferior

[Abhishek via lldb-commits]

abhishek.aggarwal added a comment.

Comments Inlined.



Comment at: 
source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp:853-854
@@ +852,4 @@
+{
+if (log)
+log->Printf("NativeRegisterContextLinux_x86_64::%s ptrace 
APIs failed to read XSAVE/FXSAVE area", __FUNCTION__);
+}

tberghammer wrote:
> Adding a log message is a good idea but please include the error message from 
> ReadFPR in the log message. It will usually contain the error message 
> returned by the ptrace call.
Error message from ReadFPR along with the error number (in case ptrace API 
fails) are displayed during call of NativeProcessLinux::PtraceWrapper(). Hence, 
to avoid multiplicity, I didn't include it here. The Log message I included is 
an additional information regarding ptrace API failure. 


http://reviews.llvm.org/D15042



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

Re: [Lldb-commits] [PATCH] D15042: PTRACE ABI to read FXSAVE area for 32-bit inferior

[Tamas Berghammer via lldb-commits]

tberghammer added inline comments.


Comment at: 
source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp:853-854
@@ +852,4 @@
+{
+if (log)
+log->Printf("NativeRegisterContextLinux_x86_64::%s ptrace 
APIs failed to read XSAVE/FXSAVE area", __FUNCTION__);
+}

Adding a log message is a good idea but please include the error message from 
ReadFPR in the log message. It will usually contain the error message returned 
by the ptrace call.


http://reviews.llvm.org/D15042



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