Re: [Lldb-commits] [lldb] r261206 - [LLDB][MIPS] Provide CPU string to compiler for appropriate code generation for MIPS
Hi Hans,
This change fixes expression related tests for MIPS release 6 architecture
(mipsr6).
Regards,
Bhushan
-Original Message-
From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of Hans
Wennborg
Sent: 23 February 2016 00:25
To: Bhushan Attarde
Cc: lldb-commits@lists.llvm.org; Greg Clayton (gclay...@apple.com);
ztur...@google.com
Subject: Re: [Lldb-commits] [lldb] r261206 - [LLDB][MIPS] Provide CPU string to
compiler for appropriate code generation for MIPS
Hi Bhushan,
This looks more like new functionality than a regression fix from 3.7.
As such, I'd rather not merge it to 3.8 this late in the process.
Thanks,
Hans
On Sun, Feb 21, 2016 at 9:08 PM, Bhushan Attarde
wrote:
> Hi Hans,
>
> Could you please add this (r261206) to the release branch?
>
> Thanks,
> Bhushan
>
>
> -Original Message-
> From: lldb-commits [mailto:lldb-commits-boun...@lists.llvm.org] On
> Behalf Of Bhushan D. Attarde via lldb-commits
> Sent: 18 February 2016 17:23
> To: lldb-commits@lists.llvm.org
> Subject: [Lldb-commits] [lldb] r261206 - [LLDB][MIPS] Provide CPU
> string to compiler for appropriate code generation for MIPS
>
> Author: bhushan.attarde
> Date: Thu Feb 18 05:53:28 2016
> New Revision: 261206
>
> URL: http://llvm.org/viewvc/llvm-project?rev=261206&view=rev
> Log:
> [LLDB][MIPS] Provide CPU string to compiler for appropriate code
> generation for MIPS
>
> SUMMARY:
> This patch implements ArchSpec::GetClangTargetCPU() that provides string
> representing current architecture as a target CPU.
> This string is then passed to tools like clang so that they generate
> correct code for that target.
>
> Reviewers: clayborg, zturner
> Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits
> Differential Revision: http://reviews.llvm.org/D17022
>
> Modified:
> lldb/trunk/include/lldb/Core/ArchSpec.h
> lldb/trunk/source/Core/ArchSpec.cpp
>
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser
> .cpp
>
> Modified: lldb/trunk/include/lldb/Core/ArchSpec.h
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/ArchS
> pec.h?rev=261206&r1=261205&r2=261206&view=diff
> ==
>
> --- lldb/trunk/include/lldb/Core/ArchSpec.h (original)
> +++ lldb/trunk/include/lldb/Core/ArchSpec.h Thu Feb 18 05:53:28 2016
> @@ -288,6 +288,16 @@ public:
> GetArchitectureName () const;
>
>
> //--
> +/// Returns a string representing current architecture as a target CPU
> +/// for tools like compiler, disassembler etc.
> +///
> +/// @return A string representing target CPU for the current
> +/// architecture.
> +//--
> +std::string
> +GetClangTargetCPU ();
> +
> +
> + //--
> /// Clears the object state.
> ///
> /// Clears the object state back to a default invalid state.
>
> Modified: lldb/trunk/source/Core/ArchSpec.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ArchSpec.cp
> p?rev=261206&r1=261205&r2=261206&view=diff
> ==
>
> --- lldb/trunk/source/Core/ArchSpec.cpp (original)
> +++ lldb/trunk/source/Core/ArchSpec.cpp Thu Feb 18 05:53:28 2016
> @@ -511,6 +511,56 @@ ArchSpec::GetArchitectureName () const
> return "unknown";
> }
>
> +std::string
> +ArchSpec::GetClangTargetCPU ()
> +{
> +std::string cpu;
> +const llvm::Triple::ArchType machine = GetMachine();
> +
> +if (machine == llvm::Triple::mips ||
> +machine == llvm::Triple::mipsel ||
> +machine == llvm::Triple::mips64 ||
> +machine == llvm::Triple::mips64el)
> +{
> +switch (m_core)
> +{
> +case ArchSpec::eCore_mips32:
> +case ArchSpec::eCore_mips32el:
> +cpu = "mips32"; break;
> +case ArchSpec::eCore_mips32r2:
> +case ArchSpec::eCore_mips32r2el:
> +cpu = "mips32r2"; break;
> +case ArchSpec::eCore_mips32r3:
> +case ArchSpec::eCore_mips32r3el:
> +cpu = "mips32r3"; break;
> +case ArchSpec::eCore_mips32r5:
> +case ArchSpec::eCore_mips32r5el:
> +cpu = "mips32r5"; break;
> +case ArchSpec::eCore_mips32r6:
> +case ArchSpec::eCore_mips32r6el:
> +cpu = "mips32r6"; break;
> +case ArchSpec::eCore_mips64:
> +case ArchSpec::eCore_mips64el:
> +cpu = "mips64"; break;
> +case ArchSpec::eCore_mips64r2:
> +case ArchSpec::eCore_mips64r2el:
> +cpu = "mips64r2"; break;
> +case ArchSpec::eCore_mips64r3:
> +case ArchSpec::eCore_mips64r3el:
> +cpu = "mips64r3"; break;
> +case ArchSpec::eCore
Re: [Lldb-commits] [PATCH] D17492: Case sensitive path compare on Windows breaks breakpoints
labath added a subscriber: labath.
Comment at: source/Core/ConstString.cpp:269
@@ +268,3 @@
+bool
+ConstString::Equals (const ConstString& lhs, const ConstString& rhs, const
bool case_sensitive)
+{
zturner wrote:
> Looks like this code also isn't clang-formatted. If you build clang-format
> (with `ninja clang-format`) and add its folder to your `PATH` environment
> variable, then when your changes are staged in git, just run `git
> clang-format`.
>
> If you've already committed you can uncommit with `git reset --soft HEAD`.
> Then they will be staged again, then you can run `git clang-format`, then
> re-add all the modified files, and then recommit.
Or, you can use `git clang-format rev` to format all changes since `rev` (you
probably want `rev`=`HEAD^`).
http://reviews.llvm.org/D17492
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r261593 - Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in source/Commands/CommandObjectCommands.cpp; other minor fixes.
I agree with Adrian. I don't think the section comments are supposed to apply to the "main header file", which should always come first. On 23 February 2016 at 00:17, Eugene Zelenko via lldb-commits wrote: > On Mon, Feb 22, 2016 at 4:14 PM, Adrian McCarthy wrote: >> It looks like this patch reorders the #includes in a way that seems contrary >> to general practice. In particular, if foo.cpp has a header foo.h, then it >> should include foo.h before any other files. This helps ensure that foo.h >> can stand alone and won't require clients to have to figure out what else >> must be included. >> >> http://llvm.org/docs/CodingStandards.html#include-style >> >> I know LLDB doesn't always follow LLVM guidelines, but this seems pretty >> common and intentional. > > I try to follow headers section comments. > > Eugene. > ___ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r261630 - XFAIL TestInlines for Linux with gcc
Author: tberghammer
Date: Tue Feb 23 05:35:38 2016
New Revision: 261630
URL: http://llvm.org/viewvc/llvm-project?rev=261630&view=rev
Log:
XFAIL TestInlines for Linux with gcc
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/TestInlines.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/TestInlines.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/TestInlines.py?rev=261630&r1=261629&r2=261630&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/TestInlines.py
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/TestInlines.py Tue
Feb 23 05:35:38 2016
@@ -4,8 +4,9 @@ from __future__ import print_function
import os, time
import lldb
+from lldbsuite.test.decorators import *
from lldbsuite.test.lldbtest import *
-import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test import lldbutil
class InlinesTestCase(TestBase):
@@ -17,6 +18,7 @@ class InlinesTestCase(TestBase):
# Find the line number to break inside main().
self.line = line_number('inlines.c', '// Set break point at this
line.')
+@expectedFailureAll("llvm.org/pr26710", oslist=["linux"], compiler="gcc")
def test(self):
"""Test that local variables are visible in expressions."""
self.build()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D17535: [LLDB][MIPS] Single step atomic sequences
labath added a subscriber: labath.
labath added a comment.
I'll leave the final review to Tamas, just a couple of comments here.
Comment at:
packages/Python/lldbsuite/test/functionalities/single_step_atomic_sequence/TestStepInAtomicSequence.py:70
@@ +69,3 @@
+inst_opcode = inst.GetMnemonic(target)
+if inst_opcode in self.atomic_start_insns:
+# Get the address of instruction starting atomic sequence
If you don't find the instructions you are looking for (perhaps due to a
compiler change), the test will end up being a no-op. You might want to assert
that you actually find the instructions you are looking for.
Comment at:
packages/Python/lldbsuite/test/functionalities/single_step_atomic_sequence/TestStepInAtomicSequence.py:94
@@ +93,3 @@
+
+print ("Sequence Starts at 0x%x:"% start_of_seq)
+print ("Sequence ends at 0x%x:"% end_of_seq)
These kinds of debug statements are usually made conditional on
`self.TraceOn()` (`-t` flag to dotest), to minimize the noise it the general
case when you're not debugging this test.
Comment at: source/Plugins/Process/Linux/NativeProcessLinux.cpp:1689
@@ -1677,6 +1688,3 @@
}
-else if (m_arch.GetMachine() == llvm::Triple::mips64
-|| m_arch.GetMachine() == llvm::Triple::mips64el
-|| m_arch.GetMachine() == llvm::Triple::mips
-|| m_arch.GetMachine() == llvm::Triple::mipsel)
-error = SetSoftwareBreakpoint(next_pc, 4);
+else if (arch_machine == llvm::Triple::mips64 ||
+ arch_machine == llvm::Triple::mips64el ||
I've been seeing this pattern a lot lately. Isn't it time to make a
`isMipsArchitecture` utility function somewhere?
Repository:
rL LLVM
http://reviews.llvm.org/D17535
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r261631 - [linux] Remove all traces of signalfd(2)
Author: labath
Date: Tue Feb 23 06:26:08 2016
New Revision: 261631
URL: http://llvm.org/viewvc/llvm-project?rev=261631&view=rev
Log:
[linux] Remove all traces of signalfd(2)
Summary:
Signalfd is not used in the code anymore, and given that the same functionality
can be achieved
with the new MainLoop class, it's unlikely we will need it in the future.
Remove all traces of
it.
Reviewers: tberghammer, ovyalov
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D17510
Removed:
lldb/trunk/include/lldb/Host/linux/Signalfd.h
Modified:
lldb/trunk/source/Host/android/LibcGlue.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
Removed: lldb/trunk/include/lldb/Host/linux/Signalfd.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/linux/Signalfd.h?rev=261630&view=auto
==
--- lldb/trunk/include/lldb/Host/linux/Signalfd.h (original)
+++ lldb/trunk/include/lldb/Host/linux/Signalfd.h (removed)
@@ -1,54 +0,0 @@
-//===-- Signalfd.h --*- C++
-*-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-
-// This file defines signalfd functions & structures
-
-#ifndef liblldb_Host_linux_Signalfd_h_
-#define liblldb_Host_linux_Signalfd_h_
-
-#ifdef __ANDROID_NDK__
-#include
-#endif
-
-#if defined(__ANDROID_API__) && __ANDROID_API__ < 21
-
-#include
-#include
-
-#define SFD_CLOEXEC O_CLOEXEC
-#define SFD_NONBLOCK O_NONBLOCK
-
-struct signalfd_siginfo {
-__u32 ssi_signo;
-__s32 ssi_errno;
-__s32 ssi_code;
-__u32 ssi_pid;
-__u32 ssi_uid;
-__s32 ssi_fd;
-__u32 ssi_tid;
-__u32 ssi_band;
-__u32 ssi_overrun;
-__u32 ssi_trapno;
-__s32 ssi_status;
-__s32 ssi_int;
-__u64 ssi_ptr;
-__u64 ssi_utime;
-__u64 ssi_stime;
-__u64 ssi_addr;
-__u16 ssi_addr_lsb;
-__u8 __pad[46];
-};
-
-int signalfd (int fd, const sigset_t *mask, int flags);
-
-#else
-#include
-#endif
-
-#endif // liblldb_Host_linux_Signalfd_h_
Modified: lldb/trunk/source/Host/android/LibcGlue.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/android/LibcGlue.cpp?rev=261631&r1=261630&r2=261631&view=diff
==
--- lldb/trunk/source/Host/android/LibcGlue.cpp (original)
+++ lldb/trunk/source/Host/android/LibcGlue.cpp Tue Feb 23 06:26:08 2016
@@ -27,11 +27,6 @@ time_t timegm(struct tm* t)
return (time_t) timegm64(t);
}
-int signalfd (int fd, const sigset_t *mask, int flags)
-{
-return syscall(__NR_signalfd4, fd, mask, _NSIG / 8, flags);
-}
-
int posix_openpt(int flags)
{
return open("/dev/ptmx", flags);
Modified: lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp?rev=261631&r1=261630&r2=261631&view=diff
==
--- lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp (original)
+++ lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp Tue Feb 23
06:26:08 2016
@@ -58,7 +58,6 @@
#include "lldb/Host/linux/Personality.h"
#include "lldb/Host/linux/Ptrace.h"
-#include "lldb/Host/linux/Signalfd.h"
#include "lldb/Host/linux/Uio.h"
#include "lldb/Host/android/Android.h"
Modified: lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp?rev=261631&r1=261630&r2=261631&view=diff
==
--- lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp (original)
+++ lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp Tue Feb 23 06:26:08 2016
@@ -414,13 +414,6 @@ main_gdbserver (int argc, char *argv[])
signal (SIGPIPE, signal_handler);
MainLoop::SignalHandleUP sighup_handle = mainloop.RegisterSignal(SIGHUP,
sighup_handler, error);
#endif
-#ifdef __linux__
-// Block delivery of SIGCHLD on linux. NativeProcessLinux will read it
using signalfd.
-sigset_t set;
-sigemptyset(&set);
-sigaddset(&set, SIGCHLD);
-pthread_sigmask(SIG_BLOCK, &set, NULL);
-#endif
const char *progname = argv[0];
const char *subcommand = argv[1];
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D17510: [linux] Remove all traces of signalfd(2)
This revision was automatically updated to reflect the committed changes.
Closed by commit rL261631: [linux] Remove all traces of signalfd(2) (authored
by labath).
Changed prior to commit:
http://reviews.llvm.org/D17510?vs=48692&id=48805#toc
Repository:
rL LLVM
http://reviews.llvm.org/D17510
Files:
lldb/trunk/include/lldb/Host/linux/Signalfd.h
lldb/trunk/source/Host/android/LibcGlue.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
Index: lldb/trunk/include/lldb/Host/linux/Signalfd.h
===
--- lldb/trunk/include/lldb/Host/linux/Signalfd.h
+++ lldb/trunk/include/lldb/Host/linux/Signalfd.h
@@ -1,54 +0,0 @@
-//===-- Signalfd.h --*- C++ -*-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-
-// This file defines signalfd functions & structures
-
-#ifndef liblldb_Host_linux_Signalfd_h_
-#define liblldb_Host_linux_Signalfd_h_
-
-#ifdef __ANDROID_NDK__
-#include
-#endif
-
-#if defined(__ANDROID_API__) && __ANDROID_API__ < 21
-
-#include
-#include
-
-#define SFD_CLOEXEC O_CLOEXEC
-#define SFD_NONBLOCK O_NONBLOCK
-
-struct signalfd_siginfo {
-__u32 ssi_signo;
-__s32 ssi_errno;
-__s32 ssi_code;
-__u32 ssi_pid;
-__u32 ssi_uid;
-__s32 ssi_fd;
-__u32 ssi_tid;
-__u32 ssi_band;
-__u32 ssi_overrun;
-__u32 ssi_trapno;
-__s32 ssi_status;
-__s32 ssi_int;
-__u64 ssi_ptr;
-__u64 ssi_utime;
-__u64 ssi_stime;
-__u64 ssi_addr;
-__u16 ssi_addr_lsb;
-__u8 __pad[46];
-};
-
-int signalfd (int fd, const sigset_t *mask, int flags);
-
-#else
-#include
-#endif
-
-#endif // liblldb_Host_linux_Signalfd_h_
Index: lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
===
--- lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
+++ lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
@@ -414,13 +414,6 @@
signal (SIGPIPE, signal_handler);
MainLoop::SignalHandleUP sighup_handle = mainloop.RegisterSignal(SIGHUP, sighup_handler, error);
#endif
-#ifdef __linux__
-// Block delivery of SIGCHLD on linux. NativeProcessLinux will read it using signalfd.
-sigset_t set;
-sigemptyset(&set);
-sigaddset(&set, SIGCHLD);
-pthread_sigmask(SIG_BLOCK, &set, NULL);
-#endif
const char *progname = argv[0];
const char *subcommand = argv[1];
Index: lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
===
--- lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
+++ lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
@@ -58,7 +58,6 @@
#include "lldb/Host/linux/Personality.h"
#include "lldb/Host/linux/Ptrace.h"
-#include "lldb/Host/linux/Signalfd.h"
#include "lldb/Host/linux/Uio.h"
#include "lldb/Host/android/Android.h"
Index: lldb/trunk/source/Host/android/LibcGlue.cpp
===
--- lldb/trunk/source/Host/android/LibcGlue.cpp
+++ lldb/trunk/source/Host/android/LibcGlue.cpp
@@ -27,11 +27,6 @@
return (time_t) timegm64(t);
}
-int signalfd (int fd, const sigset_t *mask, int flags)
-{
-return syscall(__NR_signalfd4, fd, mask, _NSIG / 8, flags);
-}
-
int posix_openpt(int flags)
{
return open("/dev/ptmx", flags);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r261636 - Work around a stepping bug in arm64 android M
Author: labath
Date: Tue Feb 23 07:56:30 2016
New Revision: 261636
URL: http://llvm.org/viewvc/llvm-project?rev=261636&view=rev
Log:
Work around a stepping bug in arm64 android M
Summary:
On arm64, linux<=4.4 and Android<=M there is a bug, which prevents
single-stepping from working when
the system comes back from suspend, because of incorrectly initialized CPUs.
This did not really
affect Androidhttp://reviews.llvm.org/D17509
Added:
lldb/trunk/source/Plugins/Process/Linux/SingleStepCheck.cpp
lldb/trunk/source/Plugins/Process/Linux/SingleStepCheck.h
Modified:
lldb/trunk/source/Plugins/Process/Linux/CMakeLists.txt
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h
lldb/trunk/source/Plugins/Process/Linux/NativeThreadLinux.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeThreadLinux.h
Modified: lldb/trunk/source/Plugins/Process/Linux/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/CMakeLists.txt?rev=261636&r1=261635&r2=261636&view=diff
==
--- lldb/trunk/source/Plugins/Process/Linux/CMakeLists.txt (original)
+++ lldb/trunk/source/Plugins/Process/Linux/CMakeLists.txt Tue Feb 23 07:56:30
2016
@@ -11,4 +11,5 @@ add_lldb_library(lldbPluginProcessLinux
NativeRegisterContextLinux_mips64.cpp
NativeThreadLinux.cpp
ProcFileReader.cpp
+ SingleStepCheck.cpp
)
Modified: lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp?rev=261636&r1=261635&r2=261636&view=diff
==
--- lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp (original)
+++ lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp Tue Feb 23
07:56:30 2016
@@ -2655,43 +2655,6 @@ NativeProcessLinux::WriteMemory(lldb::ad
}
Error
-NativeProcessLinux::Resume (lldb::tid_t tid, uint32_t signo)
-{
-Log *log (GetLogIfAllCategoriesSet (LIBLLDB_LOG_PROCESS));
-
-if (log)
-log->Printf ("NativeProcessLinux::%s() resuming thread = %" PRIu64 "
with signal %s", __FUNCTION__, tid,
- Host::GetSignalAsCString(signo));
-
-
-
-intptr_t data = 0;
-
-if (signo != LLDB_INVALID_SIGNAL_NUMBER)
-data = signo;
-
-Error error = PtraceWrapper(PTRACE_CONT, tid, nullptr, (void*)data);
-
-if (log)
-log->Printf ("NativeProcessLinux::%s() resuming thread = %" PRIu64 "
result = %s", __FUNCTION__, tid, error.Success() ? "true" : "false");
-return error;
-}
-
-Error
-NativeProcessLinux::SingleStep(lldb::tid_t tid, uint32_t signo)
-{
-intptr_t data = 0;
-
-if (signo != LLDB_INVALID_SIGNAL_NUMBER)
-data = signo;
-
-// If hardware single-stepping is not supported, we just do a continue.
The breakpoint on the
-// next instruction has been setup in NativeProcessLinux::Resume.
-return PtraceWrapper(SupportHardwareSingleStepping() ? PTRACE_SINGLESTEP :
PTRACE_CONT,
-tid, nullptr, (void*)data);
-}
-
-Error
NativeProcessLinux::GetSignalInfo(lldb::tid_t tid, void *siginfo)
{
return PtraceWrapper(PTRACE_GETSIGINFO, tid, nullptr, siginfo);
@@ -2979,16 +2942,14 @@ NativeProcessLinux::ResumeThread(NativeT
{
case eStateRunning:
{
-thread.SetRunning();
-const auto resume_result = Resume(thread.GetID(), signo);
+const auto resume_result = thread.Resume(signo);
if (resume_result.Success())
SetState(eStateRunning, true);
return resume_result;
}
case eStateStepping:
{
-thread.SetStepping();
-const auto step_result = SingleStep(thread.GetID(), signo);
+const auto step_result = thread.SingleStep(signo);
if (step_result.Success())
SetState(eStateRunning, true);
return step_result;
Modified: lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h?rev=261636&r1=261635&r2=261636&view=diff
==
--- lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h (original)
+++ lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h Tue Feb 23
07:56:30 2016
@@ -127,6 +127,9 @@ namespace process_linux {
size_t data_size = 0,
long *result = nullptr);
+bool
+SupportHardwareSingleStepping() const;
+
protected:
//
-
// NativeProcessProtocol protected interface
@@ -239,9 +242,6 @@ namespace process_linux {
void
MonitorSignal(const siginfo_t &info, NativeThr
Re: [Lldb-commits] [PATCH] D17509: Work around a stepping bug in arm64 android M
This revision was automatically updated to reflect the committed changes.
labath marked 2 inline comments as done.
Closed by commit rL261636: Work around a stepping bug in arm64 android M
(authored by labath).
Changed prior to commit:
http://reviews.llvm.org/D17509?vs=48690&id=48811#toc
Repository:
rL LLVM
http://reviews.llvm.org/D17509
Files:
lldb/trunk/source/Plugins/Process/Linux/CMakeLists.txt
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h
lldb/trunk/source/Plugins/Process/Linux/NativeThreadLinux.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeThreadLinux.h
lldb/trunk/source/Plugins/Process/Linux/SingleStepCheck.cpp
lldb/trunk/source/Plugins/Process/Linux/SingleStepCheck.h
Index: lldb/trunk/source/Plugins/Process/Linux/NativeThreadLinux.cpp
===
--- lldb/trunk/source/Plugins/Process/Linux/NativeThreadLinux.cpp
+++ lldb/trunk/source/Plugins/Process/Linux/NativeThreadLinux.cpp
@@ -14,10 +14,12 @@
#include "NativeProcessLinux.h"
#include "NativeRegisterContextLinux.h"
+#include "SingleStepCheck.h"
#include "lldb/Core/Log.h"
#include "lldb/Core/State.h"
#include "lldb/Host/HostNativeThread.h"
+#include "lldb/Host/linux/Ptrace.h"
#include "lldb/Utility/LLDBAssert.h"
#include "lldb/lldb-enumerations.h"
@@ -199,8 +201,8 @@
return Error ("Clearing hardware watchpoint failed.");
}
-void
-NativeThreadLinux::SetRunning ()
+Error
+NativeThreadLinux::Resume(uint32_t signo)
{
const StateType new_state = StateType::eStateRunning;
MaybeLogStateChange (new_state);
@@ -213,29 +215,92 @@
// then this is a new thread. So set all existing watchpoints.
if (m_watchpoint_index_map.empty())
{
-const auto process_sp = GetProcess();
-if (process_sp)
+NativeProcessLinux &process = GetProcess();
+
+const auto &watchpoint_map = process.GetWatchpointMap();
+GetRegisterContext()->ClearAllHardwareWatchpoints();
+for (const auto &pair : watchpoint_map)
{
-const auto &watchpoint_map = process_sp->GetWatchpointMap();
-if (watchpoint_map.empty()) return;
-GetRegisterContext()->ClearAllHardwareWatchpoints();
-for (const auto &pair : watchpoint_map)
-{
-const auto& wp = pair.second;
-SetWatchpoint(wp.m_addr, wp.m_size, wp.m_watch_flags, wp.m_hardware);
-}
+const auto &wp = pair.second;
+SetWatchpoint(wp.m_addr, wp.m_size, wp.m_watch_flags, wp.m_hardware);
}
}
+
+intptr_t data = 0;
+
+if (signo != LLDB_INVALID_SIGNAL_NUMBER)
+data = signo;
+
+return NativeProcessLinux::PtraceWrapper(PTRACE_CONT, GetID(), nullptr, reinterpret_cast(data));
}
void
-NativeThreadLinux::SetStepping ()
+NativeThreadLinux::MaybePrepareSingleStepWorkaround()
+{
+if (!SingleStepWorkaroundNeeded())
+return;
+
+Log *log(GetLogIfAllCategoriesSet(LIBLLDB_LOG_THREAD));
+
+if (sched_getaffinity(static_cast<::pid_t>(m_tid), sizeof m_original_cpu_set, &m_original_cpu_set) != 0)
+{
+// This should really not fail. But, just in case...
+if (log)
+{
+Error error(errno, eErrorTypePOSIX);
+log->Printf("NativeThreadLinux::%s Unable to get cpu affinity for thread %" PRIx64 ": %s", __FUNCTION__,
+m_tid, error.AsCString());
+}
+return;
+}
+
+cpu_set_t set;
+CPU_ZERO(&set);
+CPU_SET(0, &set);
+if (sched_setaffinity(static_cast<::pid_t>(m_tid), sizeof set, &set) != 0 && log)
+{
+// This may fail in very locked down systems, if the thread is not allowed to run on
+// cpu 0. If that happens, only thing we can do is it log it and continue...
+Error error(errno, eErrorTypePOSIX);
+log->Printf("NativeThreadLinux::%s Unable to set cpu affinity for thread %" PRIx64 ": %s", __FUNCTION__, m_tid,
+error.AsCString());
+}
+}
+
+void
+NativeThreadLinux::MaybeCleanupSingleStepWorkaround()
+{
+if (!SingleStepWorkaroundNeeded())
+return;
+
+if (sched_setaffinity(static_cast<::pid_t>(m_tid), sizeof m_original_cpu_set, &m_original_cpu_set) != 0)
+{
+Error error(errno, eErrorTypePOSIX);
+Log *log(GetLogIfAllCategoriesSet(LIBLLDB_LOG_THREAD));
+log->Printf("NativeThreadLinux::%s Unable to reset cpu affinity for thread %" PRIx64 ": %s", __FUNCTION__,
+m_tid, error.AsCString());
+}
+}
+
+Error
+NativeThreadLinux::SingleStep(uint32_t signo)
{
const StateType new_state = StateType::eStateStepping;
MaybeLogStateChange (new_state);
m_state = new_state;
-
m_stop_info.reason = StopReason::eStopReasonNone;
+
+MaybePrepareSingleStepWorkaround();
+
+intptr_t data = 0;
+if (signo != LLDB_INVALID_SIGNAL_
Re: [Lldb-commits] [PATCH] D17449: Handle the case when a variable is only valid in part of the enclosing scope
tberghammer added a comment. We have 2 (+1) independent dimension here: 1. List of ranges where the variable is in scope 2. List of ranges where the variable is available 3. Format of the location list (it is more of an implementation details because of a format change in dwarf5) To represent all of the possible combination for a variable we have to handle all dimension separately. I think we have several options: - Treat the scope as a top level parameter of a variable (same way as we treat the enclosing lexical block) the way I implemented it and if we are worrying about the memory implication then a possible optimization is to say that an empty location list means that the scope is the same as the enclosing block (This way we will add 2 pointer to each Variable in the general case what will be a negligible size increase). - Make DWARFExpression store 2 list of ranges (1 for the locations and 1 for the scope). I think it is a very similar implementation then the current one but with storing the data in a wrong location so I am strongly against this option. - Try to make DWARFExpression smart enough to handle the 2 layer of the location expressions (I think this is you suggestion). I think to implement this we need the following changes: - Change DWARFExpression to store a RangeMap for the location list instead of just a DataExtractor because we need some data format what can be modified instead of the current implementation where DWARFExpression stores only a DataExtractor referencing a blob of data. - Teach SymbolFileDWARF about the details of the DWARFExpression format so it can modify it. - Abuse the DWARFExpression a bit so it can return some additional value next to the result of the evaluation for the DWARFExpression. Based on the steps I listed above I don't think it is reasonable to merge the scope information into the DWARFExpression especially if we consider that dwarf expressions are used for several other thing then describing the location of variables. If we don't want to add the scoping information to the Variable class then we can go with a plan like this (I don't really like it): - Create a new DWARFVariableLocationDescription class - Remove all location list support from the DWARFExpression class so it really just evaluates dwarf expressions - In the new class store a map from address range to (dwarf expression + bitfield) where the bitfield value tell if the variable is in/out of scope and if it has/hasn't have location information I think in one side this would be a fairly clean abstraction and it would also simplify the DWARFExpression class but on the other side I am almost certain then it would have more memory and performance impact then my current implementation (especially if the memory optimization I mentioned is applied) because it will have to create a range map from each dwarf expression and store it in memory. All in all I don't really share your concern regarding memory impact, but I am happy to optimize it to the point where we use only 3 extra pointer (1 std::vector) compared to the original situation in the common (C/C++) case. Looking into the other options I don't think any of them is any better in terms of memory/performance and they will complicate the use of dwarf expressions all over lldb (the DWARFVariableLocationDescription class would make things cleaner but I don't see any good way to implement it without a higher memory penalty then my current implementation) http://reviews.llvm.org/D17449 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D17545: Fix PythonDataObjectsTests for python 2
labath created this revision. labath added a reviewer: zturner. labath added a subscriber: lldb-commits. the python2 branch seems erroneous as it expected the object to be both a "String" and "Bytes". Fix the expectation. http://reviews.llvm.org/D17545 Files: unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp Index: unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp === --- unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp +++ unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp @@ -209,14 +209,13 @@ PyObject *py_bytes = PyBytes_FromString(test_bytes); EXPECT_TRUE(PythonBytes::Check(py_bytes)); PythonBytes python_bytes(PyRefType::Owned, py_bytes); -EXPECT_EQ(PyObjectType::Bytes, python_bytes.GetObjectType()); #if PY_MAJOR_VERSION < 3 EXPECT_TRUE(PythonString::Check(py_bytes)); EXPECT_EQ(PyObjectType::String, python_bytes.GetObjectType()); #else EXPECT_FALSE(PythonString::Check(py_bytes)); -EXPECT_NE(PyObjectType::String, python_bytes.GetObjectType()); +EXPECT_EQ(PyObjectType::Bytes, python_bytes.GetObjectType()); #endif llvm::ArrayRef bytes = python_bytes.GetBytes(); Index: unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp === --- unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp +++ unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp @@ -209,14 +209,13 @@ PyObject *py_bytes = PyBytes_FromString(test_bytes); EXPECT_TRUE(PythonBytes::Check(py_bytes)); PythonBytes python_bytes(PyRefType::Owned, py_bytes); -EXPECT_EQ(PyObjectType::Bytes, python_bytes.GetObjectType()); #if PY_MAJOR_VERSION < 3 EXPECT_TRUE(PythonString::Check(py_bytes)); EXPECT_EQ(PyObjectType::String, python_bytes.GetObjectType()); #else EXPECT_FALSE(PythonString::Check(py_bytes)); -EXPECT_NE(PyObjectType::String, python_bytes.GetObjectType()); +EXPECT_EQ(PyObjectType::Bytes, python_bytes.GetObjectType()); #endif llvm::ArrayRef bytes = python_bytes.GetBytes(); ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D17492: Case sensitive path compare on Windows breaks breakpoints
zturner added inline comments.
Comment at: source/Core/ConstString.cpp:269
@@ +268,3 @@
+bool
+ConstString::Equals (const ConstString& lhs, const ConstString& rhs, const
bool case_sensitive)
+{
labath wrote:
> zturner wrote:
> > Looks like this code also isn't clang-formatted. If you build clang-format
> > (with `ninja clang-format`) and add its folder to your `PATH` environment
> > variable, then when your changes are staged in git, just run `git
> > clang-format`.
> >
> > If you've already committed you can uncommit with `git reset --soft HEAD`.
> > Then they will be staged again, then you can run `git clang-format`, then
> > re-add all the modified files, and then recommit.
> Or, you can use `git clang-format rev` to format all changes since `rev` (you
> probably want `rev`=`HEAD^`).
>
>
Neat, didn't know about this. (although on Windows you have to use either
HEAD~1 or HEAD^^, since ^ needs to be escaped. This makes it particularly
annoying if you want HEAD~2 for example, because then you need HEAD, etc.
So most people on windows use the ~n syntax.
http://reviews.llvm.org/D17492
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D17545: Fix PythonDataObjectsTests for python 2
zturner added inline comments. Comment at: unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp:212 @@ -211,3 +211,2 @@ PythonBytes python_bytes(PyRefType::Owned, py_bytes); -EXPECT_EQ(PyObjectType::Bytes, python_bytes.GetObjectType()); Seems like this check is still valid? http://reviews.llvm.org/D17545 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D17545: Fix PythonDataObjectsTests for python 2
zturner added a comment. http://reviews.llvm.org/D17545 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D17545: Fix PythonDataObjectsTests for python 2
labath added inline comments. Comment at: unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp:212 @@ -211,3 +211,2 @@ PythonBytes python_bytes(PyRefType::Owned, py_bytes); -EXPECT_EQ(PyObjectType::Bytes, python_bytes.GetObjectType()); zturner wrote: > Seems like this check is still valid? Not on python 2, I get "string" there. We can't have checks on line 212 and 216 both be true, so I assumed "string" is intended. Note that I have simply moved this check into the python-3 branch. http://reviews.llvm.org/D17545 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r261206 - [LLDB][MIPS] Provide CPU string to compiler for appropriate code generation for MIPS
Did those tests pass for mipsr6 with 3.7?
On Tue, Feb 23, 2016 at 3:19 AM, Bhushan Attarde
wrote:
> Hi Hans,
>
> This change fixes expression related tests for MIPS release 6 architecture
> (mipsr6).
>
>
> Regards,
> Bhushan
>
> -Original Message-
> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of Hans
> Wennborg
> Sent: 23 February 2016 00:25
> To: Bhushan Attarde
> Cc: lldb-commits@lists.llvm.org; Greg Clayton (gclay...@apple.com);
> ztur...@google.com
> Subject: Re: [Lldb-commits] [lldb] r261206 - [LLDB][MIPS] Provide CPU string
> to compiler for appropriate code generation for MIPS
>
> Hi Bhushan,
>
> This looks more like new functionality than a regression fix from 3.7.
> As such, I'd rather not merge it to 3.8 this late in the process.
>
> Thanks,
> Hans
>
> On Sun, Feb 21, 2016 at 9:08 PM, Bhushan Attarde
> wrote:
>> Hi Hans,
>>
>> Could you please add this (r261206) to the release branch?
>>
>> Thanks,
>> Bhushan
>>
>>
>> -Original Message-
>> From: lldb-commits [mailto:lldb-commits-boun...@lists.llvm.org] On
>> Behalf Of Bhushan D. Attarde via lldb-commits
>> Sent: 18 February 2016 17:23
>> To: lldb-commits@lists.llvm.org
>> Subject: [Lldb-commits] [lldb] r261206 - [LLDB][MIPS] Provide CPU
>> string to compiler for appropriate code generation for MIPS
>>
>> Author: bhushan.attarde
>> Date: Thu Feb 18 05:53:28 2016
>> New Revision: 261206
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=261206&view=rev
>> Log:
>> [LLDB][MIPS] Provide CPU string to compiler for appropriate code
>> generation for MIPS
>>
>> SUMMARY:
>> This patch implements ArchSpec::GetClangTargetCPU() that provides string
>> representing current architecture as a target CPU.
>> This string is then passed to tools like clang so that they generate
>> correct code for that target.
>>
>> Reviewers: clayborg, zturner
>> Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits
>> Differential Revision: http://reviews.llvm.org/D17022
>>
>> Modified:
>> lldb/trunk/include/lldb/Core/ArchSpec.h
>> lldb/trunk/source/Core/ArchSpec.cpp
>>
>> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser
>> .cpp
>>
>> Modified: lldb/trunk/include/lldb/Core/ArchSpec.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/ArchS
>> pec.h?rev=261206&r1=261205&r2=261206&view=diff
>> ==
>>
>> --- lldb/trunk/include/lldb/Core/ArchSpec.h (original)
>> +++ lldb/trunk/include/lldb/Core/ArchSpec.h Thu Feb 18 05:53:28 2016
>> @@ -288,6 +288,16 @@ public:
>> GetArchitectureName () const;
>>
>>
>> //--
>> +/// Returns a string representing current architecture as a target CPU
>> +/// for tools like compiler, disassembler etc.
>> +///
>> +/// @return A string representing target CPU for the current
>> +/// architecture.
>> +//--
>> +std::string
>> +GetClangTargetCPU ();
>> +
>> +
>> + //--
>> /// Clears the object state.
>> ///
>> /// Clears the object state back to a default invalid state.
>>
>> Modified: lldb/trunk/source/Core/ArchSpec.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ArchSpec.cp
>> p?rev=261206&r1=261205&r2=261206&view=diff
>> ==
>>
>> --- lldb/trunk/source/Core/ArchSpec.cpp (original)
>> +++ lldb/trunk/source/Core/ArchSpec.cpp Thu Feb 18 05:53:28 2016
>> @@ -511,6 +511,56 @@ ArchSpec::GetArchitectureName () const
>> return "unknown";
>> }
>>
>> +std::string
>> +ArchSpec::GetClangTargetCPU ()
>> +{
>> +std::string cpu;
>> +const llvm::Triple::ArchType machine = GetMachine();
>> +
>> +if (machine == llvm::Triple::mips ||
>> +machine == llvm::Triple::mipsel ||
>> +machine == llvm::Triple::mips64 ||
>> +machine == llvm::Triple::mips64el)
>> +{
>> +switch (m_core)
>> +{
>> +case ArchSpec::eCore_mips32:
>> +case ArchSpec::eCore_mips32el:
>> +cpu = "mips32"; break;
>> +case ArchSpec::eCore_mips32r2:
>> +case ArchSpec::eCore_mips32r2el:
>> +cpu = "mips32r2"; break;
>> +case ArchSpec::eCore_mips32r3:
>> +case ArchSpec::eCore_mips32r3el:
>> +cpu = "mips32r3"; break;
>> +case ArchSpec::eCore_mips32r5:
>> +case ArchSpec::eCore_mips32r5el:
>> +cpu = "mips32r5"; break;
>> +case ArchSpec::eCore_mips32r6:
>> +case ArchSpec::eCore_mips32r6el:
>> +cpu = "mips32r6"; break;
>> +case ArchSpec::eCore_mips64:
>> +case ArchSpec::eCore_mips64el:
>> +cpu = "mips64"; break;
>> +case ArchSpec::eCore_mip
Re: [Lldb-commits] [lldb] r261206 - [LLDB][MIPS] Provide CPU string to compiler for appropriate code generation for MIPS
These were failures with 3.7 for mipsr6.
Regards,
Bhushan
From: hwennb...@google.com [hwennb...@google.com] on behalf of Hans Wennborg
[h...@chromium.org]
Sent: Tuesday, February 23, 2016 10:29 PM
To: Bhushan Attarde
Cc: lldb-commits@lists.llvm.org; Greg Clayton (gclay...@apple.com);
ztur...@google.com
Subject: Re: [Lldb-commits] [lldb] r261206 - [LLDB][MIPS] Provide CPU string to
compiler for appropriate code generation for MIPS
Did those tests pass for mipsr6 with 3.7?
On Tue, Feb 23, 2016 at 3:19 AM, Bhushan Attarde
wrote:
> Hi Hans,
>
> This change fixes expression related tests for MIPS release 6 architecture
> (mipsr6).
>
>
> Regards,
> Bhushan
>
> -Original Message-
> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of Hans
> Wennborg
> Sent: 23 February 2016 00:25
> To: Bhushan Attarde
> Cc: lldb-commits@lists.llvm.org; Greg Clayton (gclay...@apple.com);
> ztur...@google.com
> Subject: Re: [Lldb-commits] [lldb] r261206 - [LLDB][MIPS] Provide CPU string
> to compiler for appropriate code generation for MIPS
>
> Hi Bhushan,
>
> This looks more like new functionality than a regression fix from 3.7.
> As such, I'd rather not merge it to 3.8 this late in the process.
>
> Thanks,
> Hans
>
> On Sun, Feb 21, 2016 at 9:08 PM, Bhushan Attarde
> wrote:
>> Hi Hans,
>>
>> Could you please add this (r261206) to the release branch?
>>
>> Thanks,
>> Bhushan
>>
>>
>> -Original Message-
>> From: lldb-commits [mailto:lldb-commits-boun...@lists.llvm.org] On
>> Behalf Of Bhushan D. Attarde via lldb-commits
>> Sent: 18 February 2016 17:23
>> To: lldb-commits@lists.llvm.org
>> Subject: [Lldb-commits] [lldb] r261206 - [LLDB][MIPS] Provide CPU
>> string to compiler for appropriate code generation for MIPS
>>
>> Author: bhushan.attarde
>> Date: Thu Feb 18 05:53:28 2016
>> New Revision: 261206
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=261206&view=rev
>> Log:
>> [LLDB][MIPS] Provide CPU string to compiler for appropriate code
>> generation for MIPS
>>
>> SUMMARY:
>> This patch implements ArchSpec::GetClangTargetCPU() that provides string
>> representing current architecture as a target CPU.
>> This string is then passed to tools like clang so that they generate
>> correct code for that target.
>>
>> Reviewers: clayborg, zturner
>> Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits
>> Differential Revision: http://reviews.llvm.org/D17022
>>
>> Modified:
>> lldb/trunk/include/lldb/Core/ArchSpec.h
>> lldb/trunk/source/Core/ArchSpec.cpp
>>
>> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser
>> .cpp
>>
>> Modified: lldb/trunk/include/lldb/Core/ArchSpec.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/ArchS
>> pec.h?rev=261206&r1=261205&r2=261206&view=diff
>> ==
>>
>> --- lldb/trunk/include/lldb/Core/ArchSpec.h (original)
>> +++ lldb/trunk/include/lldb/Core/ArchSpec.h Thu Feb 18 05:53:28 2016
>> @@ -288,6 +288,16 @@ public:
>> GetArchitectureName () const;
>>
>>
>> //--
>> +/// Returns a string representing current architecture as a target CPU
>> +/// for tools like compiler, disassembler etc.
>> +///
>> +/// @return A string representing target CPU for the current
>> +/// architecture.
>> +//--
>> +std::string
>> +GetClangTargetCPU ();
>> +
>> +
>> + //--
>> /// Clears the object state.
>> ///
>> /// Clears the object state back to a default invalid state.
>>
>> Modified: lldb/trunk/source/Core/ArchSpec.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ArchSpec.cp
>> p?rev=261206&r1=261205&r2=261206&view=diff
>> ==
>>
>> --- lldb/trunk/source/Core/ArchSpec.cpp (original)
>> +++ lldb/trunk/source/Core/ArchSpec.cpp Thu Feb 18 05:53:28 2016
>> @@ -511,6 +511,56 @@ ArchSpec::GetArchitectureName () const
>> return "unknown";
>> }
>>
>> +std::string
>> +ArchSpec::GetClangTargetCPU ()
>> +{
>> +std::string cpu;
>> +const llvm::Triple::ArchType machine = GetMachine();
>> +
>> +if (machine == llvm::Triple::mips ||
>> +machine == llvm::Triple::mipsel ||
>> +machine == llvm::Triple::mips64 ||
>> +machine == llvm::Triple::mips64el)
>> +{
>> +switch (m_core)
>> +{
>> +case ArchSpec::eCore_mips32:
>> +case ArchSpec::eCore_mips32el:
>> +cpu = "mips32"; break;
>> +case ArchSpec::eCore_mips32r2:
>> +case ArchSpec::eCore_mips32r2el:
>> +cpu = "mips32r2"; break;
>> +case ArchSpec::eCore_mips32r3:
>> +case ArchSp
Re: [Lldb-commits] [PATCH] D17535: [LLDB][MIPS] Single step atomic sequences
clayborg resigned from this revision. clayborg edited reviewers, added: jingham; removed: clayborg. clayborg added a comment. Looks good to me, but I think Jim Ingham should have a look in case he has anything to add since Jim is the master or stepping. Repository: rL LLVM http://reviews.llvm.org/D17535 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D17449: Handle the case when a variable is only valid in part of the enclosing scope
clayborg added a comment. In http://reviews.llvm.org/D17449#359717, @tberghammer wrote: > We have 2 (+1) independent dimension here: > > 1. List of ranges where the variable is in scope > 2. List of ranges where the variable is available > 3. Format of the location list (it is more of an implementation details > because of a format change in dwarf5) > > To represent all of the possible combination for a variable we have to > handle all dimension separately. I think we have several options: > 4. Treat the scope as a top level parameter of a variable (same way as we > treat the enclosing lexical block) the way I implemented it and if we are > worrying about the memory implication then a possible optimization is to say > that an empty location list means that the scope is the same as the enclosing > block (This way we will add 2 pointer to each Variable in the general case > what will be a negligible size increase). > 5. Make DWARFExpression store 2 list of ranges (1 for the locations and 1 for > the scope). I think it is a very similar implementation then the current one > but with storing the data in a wrong location so I am strongly against this > option. > 6. Try to make DWARFExpression smart enough to handle the 2 layer of the > location expressions (I think this is you suggestion). I think to implement > this we need the following changes: > - Change DWARFExpression to store a RangeMap DataExtractor> for the location list instead of just a DataExtractor because > we need some data format what can be modified instead of the current > implementation where DWARFExpression stores only a DataExtractor referencing > a blob of data. > - Teach SymbolFileDWARF about the details of the DWARFExpression format so > it can modify it. > - Abuse the DWARFExpression a bit so it can return some additional value > next to the result of the evaluation for the DWARFExpression. > > Based on the steps I listed above I don't think it is reasonable to merge > the scope information into the DWARFExpression especially if we consider that > dwarf expressions are used for several other thing then describing the > location of variables. If we don't want to add the scoping information to the > Variable class then we can go with a plan like this (I don't really like it): > 7. Create a new DWARFVariableLocationDescription class > 8. Remove all location list support from the DWARFExpression class so it > really just evaluates dwarf expressions > 9. In the new class store a map from address range to (dwarf expression + > bitfield) where the bitfield value tell if the variable is in/out of scope > and if it has/hasn't have location information > > I think in one side this would be a fairly clean abstraction and it would > also simplify the DWARFExpression class but on the other side I am almost > certain then it would have more memory and performance impact then my current > implementation (especially if the memory optimization I mentioned is applied) > because it will have to create a range map from each dwarf expression and > store it in memory. > > All in all I don't really share your concern regarding memory impact, but I > am happy to optimize it to the point where we use only 3 extra pointer (1 > std::vector) compared to the original situation in the common (C/C++) case. > Looking into the other options I don't think any of them is any better in > terms of memory/performance and they will complicate the use of dwarf > expressions all over lldb (the DWARFVariableLocationDescription class would > make things cleaner but I don't see any good way to implement it without a > higher memory penalty then my current implementation) I can see your point. I don't want to change the DWARFExpression class to just contain a list of ranges and have DWARFExpression _only_ parse single DWARF location expressions because this will cause us to have to parse the information and pull out the addresses just so we can put it into a variable that may never get displayed and this is work we don't need to do. It is actually stored in the DWARF (if the DW_AT_locations has a reference it becomes an offset into the .debug_loc section which contains data already encoded with start address, end address, block, repeat until terminate), so lets not change DWARFExpression. How about we add the in scope range list that was previously added to the variable to the DWARFExpression class instead? Just in case we have things other that a variable that has a DW_AT_location or DW_AT_data_member_location that also use the DW_AT_start_scope. Then you can ask your DWARFExpression if it is in scope before evaluating it. Then if the in scope range list is empty, it is in scope. Then we check if we have a location list, if we do, make sure the address is in one of those ranges and if not the variable is not available. Else find the right location expression and evaluate it. How does that sound? http://revi
Re: [Lldb-commits] [PATCH] D17535: [LLDB][MIPS] Single step atomic sequences
tberghammer added a comment. I am not sure I agree with the following starting point of the CL (I know about the similar functionality in GDB) and even if we agree in it I think you are handling a very small fraction of the problems. > LLDB should treat all instructions in the atomic sequence as if they are a > single instruction i.e as a "single instruction block". I think there are 3 scenario around atomic sequences: 1. You are setting a breakpoint what fails inside of the atomic sequence 2. You are line level stepping over an atomic sequence 3. You are instruction level single stepping over an atomic sequence For me the expected behavior in scenario 1 and 2 is to set the breakpoint at the address specified and handle the atomic sequence when you try to continue from the breakpoint (I hope that the compilers are generally not putting line breaks / symbols in the middle of an atomic sequence). I think the 3. scenario will happen when you are doing assembly level debugging of an atomic sequence where I would expect to step only 1 instruction as I am debugging assembly code. If I understand your CL correctly then you only handle the scenario when we are single stepping from an LL instruction. This definitely not solving the issue when an we setting a breakpoint in the middle of an atomic sequence and then try to continue from there while it is preventing the user from doing an instruction level debugging of the atomic sequences. I would be more happy with the following functionalities (not necessarily implementing all edge case for the first iteration): - Step instruction behaves as it did before (1 instruction, ignores the atomic sequence) - If we continue from a breakpoint placed inside an atomic sequence then we put back the breakpoint only after we left the atomic sequence Please let me know what do you think. P.S.: Have you hit any issue regarding atomic sequences during regular debugging? I would be interested about a usecase when they are affecting the debug experience so we can target the problematic point. Repository: rL LLVM http://reviews.llvm.org/D17535 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D17449: Handle the case when a variable is only valid in part of the enclosing scope
tberghammer added a comment. I can live with that but I still think the scope information belongs to the variable and not to the DWARF expression representing it's location. As far as I see keeping the information inside the variable have lower memory impact (assuming an empty list means full scope) because we have less Variable object then DWARFExpression object and it isn't complicate other use cases of DWARFExpression where scope isn't used at all. So all in all I can move the information to the DWARFExpression but I think keeping them in the Variable class is better. Let me know what do you think. http://reviews.llvm.org/D17449 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r261593 - Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in source/Commands/CommandObjectCommands.cpp; other minor fixes.
+1 We put the header file first immediately after the header comment in the .cpp file. The reason is that if you put the .cpp file's associated .h file in the project include headers section, then it would be easy to accidentally put another "project include" in front of the associated one (for instance because you are also supposed to arrange them alphabetically.) The llvm coding conventions also say putting prominently first is for documentation purposes - showing where to find the interface for this .cpp file, which is a little harder to see if buried in the project includes. Jim > On Feb 23, 2016, at 3:27 AM, Pavel Labath via lldb-commits > wrote: > > I agree with Adrian. I don't think the section comments are supposed > to apply to the "main header file", which should always come first. > > On 23 February 2016 at 00:17, Eugene Zelenko via lldb-commits > wrote: >> On Mon, Feb 22, 2016 at 4:14 PM, Adrian McCarthy wrote: >>> It looks like this patch reorders the #includes in a way that seems contrary >>> to general practice. In particular, if foo.cpp has a header foo.h, then it >>> should include foo.h before any other files. This helps ensure that foo.h >>> can stand alone and won't require clients to have to figure out what else >>> must be included. >>> >>> http://llvm.org/docs/CodingStandards.html#include-style >>> >>> I know LLDB doesn't always follow LLVM guidelines, but this seems pretty >>> common and intentional. >> >> I try to follow headers section comments. >> >> Eugene. >> ___ >> lldb-commits mailing list >> lldb-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > ___ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D17449: Handle the case when a variable is only valid in part of the enclosing scope
clayborg added a comment. In http://reviews.llvm.org/D17449#359874, @tberghammer wrote: > I can live with that but I still think the scope information belongs to the > variable and not to the DWARF expression representing it's location. As far > as I see keeping the information inside the variable have lower memory impact > (assuming an empty list means full scope) because we have less Variable > object then DWARFExpression object and it isn't complicate other use cases of > DWARFExpression where scope isn't used at all. > > So all in all I can move the information to the DWARFExpression but I think > keeping them in the Variable class is better. Let me know what do you think. I would vote for modifying the DWARFExpression only because we might eventually have other DIEs that have locations and start scope attributes that might use DWARFExpressions. But I don't see a problem with either if you really feel strongly... http://reviews.llvm.org/D17449 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D17535: [LLDB][MIPS] Single step atomic sequences
jingham requested changes to this revision. jingham added a comment. This revision now requires changes to proceed. IIUC, what you are doing here is when lldb-server gets a "step instruction" request that would step into one of these atomic regions, it sets a bunch of breakpoints on it's end (not telling the LLDB stepping machinery what is going on), and continues till it hits one of these. Then it will end up not where the thread plans expect it to at all, but presumably they will just have to cope? That doesn't seem the right way to go about this, since it means that you can't do any reasoning based on what the stepping machinery was trying to achieve. It would be better to wire this into the ThreadPlanStepRange's AddNextRangeBreakpoint. That's where we are doing "I want to make the next step within this range". Usually we just run to the next branch, setting breakpoints to do that. Or we single step if we are on a branch. But there's no reason that's the only thing we can do here. This would be much better because we could decide whether to do this (because we are source line stepping) or not (because we are instruction stepping) etc. We could also do things like warn if the compiler accidentally puts a line break in the middle of an atomic region. This would make the kind of considerations Tamas mentioned possible, whereas if you do things behind the stepping machinery's back, we're can't do this, and will probably end up confused in other ways as well. Repository: rL LLVM http://reviews.llvm.org/D17535 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r261704 - When looking for symbols, find load addresses in a more robust way.
Author: spyffe
Date: Tue Feb 23 17:09:06 2016
New Revision: 261704
URL: http://llvm.org/viewvc/llvm-project?rev=261704&view=rev
Log:
When looking for symbols, find load addresses in a more robust way.
IRExecutionUnit previously replicated a bunch of logic that already
existed elsewhere for the purpose of getting a load address for a
symbol. This approach failed to resolve certain types of symbols.
Instead, we now use functions on SymbolContext to do the address
resolution.
This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a
latent bug where we looked at the wrong SymbolContext to determine
whether or not it is external.
Modified:
lldb/trunk/source/Expression/IRExecutionUnit.cpp
Modified: lldb/trunk/source/Expression/IRExecutionUnit.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/IRExecutionUnit.cpp?rev=261704&r1=261703&r2=261704&view=diff
==
--- lldb/trunk/source/Expression/IRExecutionUnit.cpp (original)
+++ lldb/trunk/source/Expression/IRExecutionUnit.cpp Tue Feb 23 17:09:06 2016
@@ -769,9 +769,62 @@ IRExecutionUnit::CollectCandidateCPlusPl
lldb::addr_t
IRExecutionUnit::FindInSymbols(const std::vector
&specs, const lldb_private::SymbolContext &sc)
{
+Target *target = sc.target_sp.get();
+
+if (!target)
+{
+// we shouldn't be doing any symbol lookup at all without a target
+return LLDB_INVALID_ADDRESS;
+}
+
for (const SearchSpec &spec : specs)
{
SymbolContextList sc_list;
+
+lldb::addr_t best_internal_load_address = LLDB_INVALID_ADDRESS;
+
+std::function get_external_load_address =
+[&best_internal_load_address, target](lldb::addr_t &load_address,
+ SymbolContextList &sc_list,
+ const
lldb_private::SymbolContext &sc) -> lldb::addr_t
+{
+load_address = LLDB_INVALID_ADDRESS;
+
+for (size_t si = 0, se = sc_list.GetSize(); si < se; ++si)
+{
+SymbolContext candidate_sc;
+
+sc_list.GetContextAtIndex(si, candidate_sc);
+
+const bool is_external = (candidate_sc.function) ||
+ (candidate_sc.symbol &&
candidate_sc.symbol->IsExternal());
+
+AddressRange range;
+
+if (candidate_sc.GetAddressRange(lldb::eSymbolContextFunction
| lldb::eSymbolContextSymbol,
+ 0,
+ false,
+ range))
+{
+load_address =
range.GetBaseAddress().GetCallableLoadAddress(target);
+
+if (load_address != LLDB_INVALID_ADDRESS)
+{
+if (is_external)
+{
+return true;
+}
+else if (best_internal_load_address ==
LLDB_INVALID_ADDRESS)
+{
+best_internal_load_address = load_address;
+load_address = LLDB_INVALID_ADDRESS;
+}
+}
+}
+}
+
+return false;
+};
if (sc.module_sp)
{
@@ -783,6 +836,17 @@ IRExecutionUnit::FindInSymbols(const std
true, // append
sc_list);
}
+
+lldb::addr_t load_address = LLDB_INVALID_ADDRESS;
+
+if (get_external_load_address(load_address, sc_list, sc))
+{
+return load_address;
+}
+else
+{
+sc_list.Clear();
+}
if (sc_list.GetSize() == 0 && sc.target_sp)
{
@@ -794,49 +858,26 @@ IRExecutionUnit::FindInSymbols(const std
sc_list);
}
+if (get_external_load_address(load_address, sc_list, sc))
+{
+return load_address;
+}
+else
+{
+sc_list.Clear();
+}
+
if (sc_list.GetSize() == 0 && sc.target_sp)
{
sc.target_sp->GetImages().FindSymbolsWithNameAndType(spec.name,
lldb::eSymbolTypeAny, sc_list);
}
-lldb::addr_t best_internal_load_address = LLDB_INVALID_ADDRESS;
-
-for (size_t si = 0, se = sc_list.GetSize(); si < se; ++si)
+if (get_external_load_address(load_address, sc_list, sc))
{
-bool is_external = false;
-
-SymbolContext candidate_sc;
-
-sc_list.GetContextAtIndex(si, candidate_sc);
-if (candidate_sc.function)
-{
-is_external =
Re: [Lldb-commits] [PATCH] D17465: Get register context for the 32-bit process in a WoW64 process minidump.
amccarth updated this revision to Diff 48863.
amccarth added a comment.
Adds some very basic tests using a check-in minidump captured with Task Manager.
What we can do in the test is limited because the minidump doesn't seem to have
an exception record (thus the thread isn't stopped). I plan to look into this
in the future. There's a chance we can get this information from the thread
environment block (TEB).
http://reviews.llvm.org/D17465
Files:
packages/Python/lldbsuite/test/functionalities/postmortem/wow64_minidump/TestWow64MiniDump.py
packages/Python/lldbsuite/test/functionalities/postmortem/wow64_minidump/fizzbuzz.cpp
packages/Python/lldbsuite/test/functionalities/postmortem/wow64_minidump/fizzbuzz_wow64.dmp
source/Plugins/Process/Windows/Common/NtStructures.h
source/Plugins/Process/Windows/MiniDump/ProcessWinMiniDump.cpp
Index: source/Plugins/Process/Windows/MiniDump/ProcessWinMiniDump.cpp
===
--- source/Plugins/Process/Windows/MiniDump/ProcessWinMiniDump.cpp
+++ source/Plugins/Process/Windows/MiniDump/ProcessWinMiniDump.cpp
@@ -35,6 +35,9 @@
#include "llvm/Support/Format.h"
#include "llvm/Support/raw_ostream.h"
+#include "Plugins/Process/Windows/Common/NtStructures.h"
+#include "Plugins/Process/Windows/Common/ProcessWindowsLog.h"
+
#include "ExceptionRecord.h"
#include "ThreadWinMiniDump.h"
@@ -83,6 +86,7 @@
HANDLE m_mapping; // handle to the file mapping for the minidump file
void * m_base_addr; // base memory address of the minidump
std::shared_ptr m_exception_sp;
+bool m_is_wow64; // minidump is of a 32-bit process captured with a 64-bit debugger
};
ConstString
@@ -195,7 +199,47 @@
auto thread_sp = std::make_shared(*this, mini_dump_thread.ThreadId);
if (mini_dump_thread.ThreadContext.DataSize >= sizeof(CONTEXT))
{
-const CONTEXT *context = reinterpret_cast(static_cast(m_data_up->m_base_addr) + mini_dump_thread.ThreadContext.Rva);
+const CONTEXT *context = reinterpret_cast(
+static_cast(m_data_up->m_base_addr) + mini_dump_thread.ThreadContext.Rva);
+
+if (m_data_up->m_is_wow64)
+{
+// On Windows, a 32-bit process can run on a 64-bit machine under WOW64.
+// If the minidump was captured with a 64-bit debugger, then the CONTEXT
+// we just grabbed from the mini_dump_thread is the one for the 64-bit
+// "native" process rather than the 32-bit "guest" process we care about.
+// In this case, we can get the 32-bit CONTEXT from the TEB (Thread
+// Environment Block) of the 64-bit process.
+Error error;
+TEB64 wow64teb = {0};
+ReadMemory(mini_dump_thread.Teb, &wow64teb, sizeof(wow64teb), error);
+if (error.Success())
+{
+// Slot 1 of the thread-local storage in the 64-bit TEB points to a structure
+// that includes the 32-bit CONTEXT (after a ULONG).
+// See: https://msdn.microsoft.com/en-us/library/ms681670.aspx
+const size_t addr = wow64teb.TlsSlots[1];
+Range range = {0};
+if (FindMemoryRange(addr, &range))
+{
+lldbassert(range.start <= addr);
+const size_t offset = addr - range.start + sizeof(ULONG);
+if (offset < range.size)
+{
+const size_t overlap = range.size - offset;
+if (overlap >= sizeof(CONTEXT))
+{
+context = reinterpret_cast(range.ptr + offset);
+}
+}
+}
+}
+
+// NOTE: We don't currently use the TEB for anything else. If we need it in
+// the future, the 32-bit TEB is located according to the address stored in the
+// first slot of the 64-bit TEB (wow64teb.Reserved1[0]).
+}
+
thread_sp->SetContext(context);
}
new_thread_list.AddThread(thread_sp);
@@ -347,11 +391,8 @@
return ArchSpec();
}
-
-ProcessWinMiniDump::Data::Data() :
-m_dump_file(INVALID_HANDLE_VALUE),
-m_mapping(NULL),
-m_base_addr(nullptr)
+ProcessWinMiniDump::Data::Data()
+: m_dump_file(INVALID_HANDLE_VALUE), m_mapping(NULL), m_base_addr(nullptr), m_is_wow64(false)
{
}
@@ -381,7 +422,8 @@
auto mem_list_stream = static_cast(FindDumpStream(MemoryListStream, &stream_size));
if (mem_list_stream)
{
-for
Re: [Lldb-commits] [lldb] r261704 - When looking for symbols, find load addresses in a more robust way.
Hi Sean,
On Linux with i386 inferiors,
range.GetBaseAddress().GetCallableLoadAddress(target);
returns the wrong load address for strlen, while
candidate_sc.symbol->ResolveCallableAddress(*target);
returns the correct load address.
This is causing TestCStrings to fail on our bot:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/11726
Do you know why this might be happening?
May I revert back to using
candidate_sc.symbol->ResolveCallableAddress(*target);
and
candidate_sc.symbol->GetAddress().GetLoadAddress(target);
while you look into it?
On Tue, Feb 23, 2016 at 3:13 PM Sean Callanan via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: spyffe
> Date: Tue Feb 23 17:09:06 2016
> New Revision: 261704
>
> URL: http://llvm.org/viewvc/llvm-project?rev=261704&view=rev
> Log:
> When looking for symbols, find load addresses in a more robust way.
>
> IRExecutionUnit previously replicated a bunch of logic that already
> existed elsewhere for the purpose of getting a load address for a
> symbol. This approach failed to resolve certain types of symbols.
> Instead, we now use functions on SymbolContext to do the address
> resolution.
>
> This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a
> latent bug where we looked at the wrong SymbolContext to determine
> whether or not it is external.
>
>
>
> Modified:
> lldb/trunk/source/Expression/IRExecutionUnit.cpp
>
> Modified: lldb/trunk/source/Expression/IRExecutionUnit.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/IRExecutionUnit.cpp?rev=261704&r1=261703&r2=261704&view=diff
>
> ==
> --- lldb/trunk/source/Expression/IRExecutionUnit.cpp (original)
> +++ lldb/trunk/source/Expression/IRExecutionUnit.cpp Tue Feb 23 17:09:06
> 2016
> @@ -769,9 +769,62 @@ IRExecutionUnit::CollectCandidateCPlusPl
> lldb::addr_t
> IRExecutionUnit::FindInSymbols(const
> std::vector &specs, const
> lldb_private::SymbolContext &sc)
> {
> +Target *target = sc.target_sp.get();
> +
> +if (!target)
> +{
> +// we shouldn't be doing any symbol lookup at all without a target
> +return LLDB_INVALID_ADDRESS;
> +}
> +
> for (const SearchSpec &spec : specs)
> {
> SymbolContextList sc_list;
> +
> +lldb::addr_t best_internal_load_address = LLDB_INVALID_ADDRESS;
> +
> +std::function lldb_private::SymbolContext &)> get_external_load_address =
> +[&best_internal_load_address, target](lldb::addr_t
> &load_address,
> + SymbolContextList
> &sc_list,
> + const
> lldb_private::SymbolContext &sc) -> lldb::addr_t
> +{
> +load_address = LLDB_INVALID_ADDRESS;
> +
> +for (size_t si = 0, se = sc_list.GetSize(); si < se; ++si)
> +{
> +SymbolContext candidate_sc;
> +
> +sc_list.GetContextAtIndex(si, candidate_sc);
> +
> +const bool is_external = (candidate_sc.function) ||
> + (candidate_sc.symbol &&
> candidate_sc.symbol->IsExternal());
> +
> +AddressRange range;
> +
> +if
> (candidate_sc.GetAddressRange(lldb::eSymbolContextFunction |
> lldb::eSymbolContextSymbol,
> + 0,
> + false,
> + range))
> +{
> +load_address =
> range.GetBaseAddress().GetCallableLoadAddress(target);
> +
> +if (load_address != LLDB_INVALID_ADDRESS)
> +{
> +if (is_external)
> +{
> +return true;
> +}
> +else if (best_internal_load_address ==
> LLDB_INVALID_ADDRESS)
> +{
> +best_internal_load_address = load_address;
> +load_address = LLDB_INVALID_ADDRESS;
> +}
> +}
> +}
> +}
> +
> +return false;
> +};
>
> if (sc.module_sp)
> {
> @@ -783,6 +836,17 @@ IRExecutionUnit::FindInSymbols(const std
> true, // append
> sc_list);
> }
> +
> +lldb::addr_t load_address = LLDB_INVALID_ADDRESS;
> +
> +if (get_external_load_address(load_address, sc_list, sc))
> +{
> +return load_address;
> +}
> +else
> +{
> +sc_list.Clear();
> +}
>
> if (sc_list.GetSize() == 0 && sc.target_sp)
> {
> @@ -794,49 +858,26 @@ IRExecutionUnit::FindInSymbols(const std
>
[Lldb-commits] [PATCH] D17557: Fix TestCStrings for Linux with i386 inferiors.
chaoren created this revision.
chaoren added a reviewer: spyffe.
chaoren added a subscriber: lldb-commits.
Temporarily revert part of r261704.
http://reviews.llvm.org/D17557
Files:
source/Expression/IRExecutionUnit.cpp
Index: source/Expression/IRExecutionUnit.cpp
===
--- source/Expression/IRExecutionUnit.cpp
+++ source/Expression/IRExecutionUnit.cpp
@@ -213,7 +213,7 @@
InstructionList &instruction_list = disassembler_sp->GetInstructionList();
instruction_list.Dump(&stream, true, true, &exe_ctx);
-
+
// FIXME: The DisassemblerLLVMC has a reference cycle and won't go away if it has any active instructions.
// I'll fix that but for now, just clear the list and it will go away nicely.
disassembler_sp->GetInstructionList().Clear();
@@ -297,7 +297,7 @@
{
relocModel = llvm::Reloc::PIC_;
}
-
+
// This will be small for 32-bit and large for 64-bit.
codeModel = llvm::CodeModel::JITDefault;
@@ -325,7 +325,7 @@
mAttrs);
m_execution_engine_ap.reset(builder.create(target_machine));
-
+
m_strip_underscore = (m_execution_engine_ap->getDataLayout().getGlobalPrefix() == '_');
if (!m_execution_engine_ap.get())
@@ -373,27 +373,27 @@
if (m_failed_lookups.size())
{
StreamString ss;
-
+
ss.PutCString("Couldn't lookup symbols:\n");
-
+
bool emitNewLine = false;
-
+
for (const ConstString &failed_lookup : m_failed_lookups)
{
if (emitNewLine)
ss.PutCString("\n");
emitNewLine = true;
ss.PutCString(" ");
ss.PutCString(Mangled(failed_lookup).GetDemangledName(lldb::eLanguageTypeObjC_plus_plus).AsCString());
}
-
+
m_failed_lookups.clear();
-
+
error.SetErrorString(ss.GetData());
-
+
return;
}
-
+
m_function_load_addr = LLDB_INVALID_ADDRESS;
m_function_end_load_addr = LLDB_INVALID_ADDRESS;
@@ -446,7 +446,7 @@
else
{
record.dump(log);
-
+
DataExtractor my_extractor ((const void*)record.m_host_address, record.m_size, lldb::eByteOrderBig, 8);
my_extractor.PutToLog(log, 0, record.m_size, record.m_host_address, 16, DataExtractor::TypeUInt8);
}
@@ -731,29 +731,29 @@
{
Mangled mangled(name, true);
ConstString demangled = mangled.GetDemangledName(lldb::eLanguageTypeC_plus_plus);
-
+
if (demangled)
{
ConstString best_alternate_mangled_name = FindBestAlternateMangledName(demangled, lldb::eLanguageTypeC_plus_plus, sc);
-
+
if (best_alternate_mangled_name)
{
CPP_specs.push_back(best_alternate_mangled_name);
}
-
+
CPP_specs.push_back(SearchSpec(demangled, lldb::eFunctionNameTypeFull));
}
}
-
+
// Maybe we're looking for a const symbol but the debug info told us it was const...
if (!strncmp(name.GetCString(), "_ZN", 3) &&
strncmp(name.GetCString(), "_ZNK", 4))
{
std::string fixed_scratch("_ZNK");
fixed_scratch.append(name.GetCString() + 3);
CPP_specs.push_back(ConstString(fixed_scratch.c_str()));
}
-
+
// Maybe we're looking for a static symbol but we thought it was global...
if (!strncmp(name.GetCString(), "_Z", 2) &&
strncmp(name.GetCString(), "_ZL", 3))
@@ -799,33 +799,28 @@
const bool is_external = (candidate_sc.function) ||
(candidate_sc.symbol && candidate_sc.symbol->IsExternal());
-AddressRange range;
+load_address = candidate_sc.symbol->ResolveCallableAddress(*target);
-if (candidate_sc.GetAddressRange(lldb::eSymbolContextFunction | lldb::eSymbolContextSymbol,
- 0,
- false,
- range))
-{
-load_address = range.GetBaseAddress().GetCallableLoadAddress(target);
+if (load_address == LLDB_INVALID_ADDRESS)
+load_address = candidate_sc.symbol->GetAddress().GetLoadAddress(sc.target_sp.get());
-if (load_address != LLDB_INVALID_ADDRESS)
+if (load_address != LLDB_INVALID_ADDRESS)
+{
+if (is_external)
{
-if (is_external)
-{
-return true;
-
Re: [Lldb-commits] [PATCH] D17557: Fix TestCStrings for Linux with i386 inferiors.
chaoren updated this revision to Diff 48867.
chaoren added a comment.
Use target instead of sc.target_sp.get().
http://reviews.llvm.org/D17557
Files:
source/Expression/IRExecutionUnit.cpp
Index: source/Expression/IRExecutionUnit.cpp
===
--- source/Expression/IRExecutionUnit.cpp
+++ source/Expression/IRExecutionUnit.cpp
@@ -213,7 +213,7 @@
InstructionList &instruction_list = disassembler_sp->GetInstructionList();
instruction_list.Dump(&stream, true, true, &exe_ctx);
-
+
// FIXME: The DisassemblerLLVMC has a reference cycle and won't go away if it has any active instructions.
// I'll fix that but for now, just clear the list and it will go away nicely.
disassembler_sp->GetInstructionList().Clear();
@@ -297,7 +297,7 @@
{
relocModel = llvm::Reloc::PIC_;
}
-
+
// This will be small for 32-bit and large for 64-bit.
codeModel = llvm::CodeModel::JITDefault;
@@ -325,7 +325,7 @@
mAttrs);
m_execution_engine_ap.reset(builder.create(target_machine));
-
+
m_strip_underscore = (m_execution_engine_ap->getDataLayout().getGlobalPrefix() == '_');
if (!m_execution_engine_ap.get())
@@ -373,27 +373,27 @@
if (m_failed_lookups.size())
{
StreamString ss;
-
+
ss.PutCString("Couldn't lookup symbols:\n");
-
+
bool emitNewLine = false;
-
+
for (const ConstString &failed_lookup : m_failed_lookups)
{
if (emitNewLine)
ss.PutCString("\n");
emitNewLine = true;
ss.PutCString(" ");
ss.PutCString(Mangled(failed_lookup).GetDemangledName(lldb::eLanguageTypeObjC_plus_plus).AsCString());
}
-
+
m_failed_lookups.clear();
-
+
error.SetErrorString(ss.GetData());
-
+
return;
}
-
+
m_function_load_addr = LLDB_INVALID_ADDRESS;
m_function_end_load_addr = LLDB_INVALID_ADDRESS;
@@ -446,7 +446,7 @@
else
{
record.dump(log);
-
+
DataExtractor my_extractor ((const void*)record.m_host_address, record.m_size, lldb::eByteOrderBig, 8);
my_extractor.PutToLog(log, 0, record.m_size, record.m_host_address, 16, DataExtractor::TypeUInt8);
}
@@ -731,29 +731,29 @@
{
Mangled mangled(name, true);
ConstString demangled = mangled.GetDemangledName(lldb::eLanguageTypeC_plus_plus);
-
+
if (demangled)
{
ConstString best_alternate_mangled_name = FindBestAlternateMangledName(demangled, lldb::eLanguageTypeC_plus_plus, sc);
-
+
if (best_alternate_mangled_name)
{
CPP_specs.push_back(best_alternate_mangled_name);
}
-
+
CPP_specs.push_back(SearchSpec(demangled, lldb::eFunctionNameTypeFull));
}
}
-
+
// Maybe we're looking for a const symbol but the debug info told us it was const...
if (!strncmp(name.GetCString(), "_ZN", 3) &&
strncmp(name.GetCString(), "_ZNK", 4))
{
std::string fixed_scratch("_ZNK");
fixed_scratch.append(name.GetCString() + 3);
CPP_specs.push_back(ConstString(fixed_scratch.c_str()));
}
-
+
// Maybe we're looking for a static symbol but we thought it was global...
if (!strncmp(name.GetCString(), "_Z", 2) &&
strncmp(name.GetCString(), "_ZL", 3))
@@ -799,33 +799,28 @@
const bool is_external = (candidate_sc.function) ||
(candidate_sc.symbol && candidate_sc.symbol->IsExternal());
-AddressRange range;
+load_address = candidate_sc.symbol->ResolveCallableAddress(*target);
-if (candidate_sc.GetAddressRange(lldb::eSymbolContextFunction | lldb::eSymbolContextSymbol,
- 0,
- false,
- range))
-{
-load_address = range.GetBaseAddress().GetCallableLoadAddress(target);
+if (load_address == LLDB_INVALID_ADDRESS)
+load_address = candidate_sc.symbol->GetAddress().GetLoadAddress(target);
-if (load_address != LLDB_INVALID_ADDRESS)
+if (load_address != LLDB_INVALID_ADDRESS)
+{
+if (is_external)
{
-if (is_external)
-{
-return true;
-}
-else if (bes
Re: [Lldb-commits] [PATCH] D17492: Case sensitive path compare on Windows breaks breakpoints
Honsik updated the summary for this revision.
Honsik updated this revision to Diff 48871.
Honsik added a comment.
I added requested changes.
http://reviews.llvm.org/D17492
Files:
include/lldb/Core/ConstString.h
include/lldb/Host/FileSpec.h
packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_case_sensitivity/Makefile
packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_case_sensitivity/TestBreakpointCaseSensitivity.py
packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_case_sensitivity/main.c
source/Core/ConstString.cpp
source/Core/FileSpecList.cpp
source/Host/common/FileSpec.cpp
Index: source/Host/common/FileSpec.cpp
===
--- source/Host/common/FileSpec.cpp
+++ source/Host/common/FileSpec.cpp
@@ -396,60 +396,62 @@
bool
FileSpec::operator== (const FileSpec& rhs) const
{
-if (m_filename == rhs.m_filename)
+// case sensitivity of equality test
+const bool case_sensitive = IsCaseSensitive() || rhs.IsCaseSensitive();
+
+if (!ConstString::Equals(m_filename, rhs.m_filename, case_sensitive))
+return false;
+
+if (ConstString::Equals(m_directory, rhs.m_directory, case_sensitive))
+return true;
+
+// TODO: determine if we want to keep this code in here.
+// The code below was added to handle a case where we were
+// trying to set a file and line breakpoint and one path
+// was resolved, and the other not and the directory was
+// in a mount point that resolved to a more complete path:
+// "/tmp/a.c" == "/private/tmp/a.c". I might end up pulling
+// this out...
+if (IsResolved() && rhs.IsResolved())
{
-if (m_directory == rhs.m_directory)
-return true;
-
-// TODO: determine if we want to keep this code in here.
-// The code below was added to handle a case where we were
-// trying to set a file and line breakpoint and one path
-// was resolved, and the other not and the directory was
-// in a mount point that resolved to a more complete path:
-// "/tmp/a.c" == "/private/tmp/a.c". I might end up pulling
-// this out...
-if (IsResolved() && rhs.IsResolved())
-{
-// Both paths are resolved, no need to look further...
-return false;
-}
-
-FileSpec resolved_lhs(*this);
+// Both paths are resolved, no need to look further...
+return false;
+}
+
+FileSpec resolved_lhs(*this);
-// If "this" isn't resolved, resolve it
-if (!IsResolved())
+// If "this" isn't resolved, resolve it
+if (!IsResolved())
+{
+if (resolved_lhs.ResolvePath())
{
-if (resolved_lhs.ResolvePath())
-{
-// This path wasn't resolved but now it is. Check if the resolved
-// directory is the same as our unresolved directory, and if so,
-// we can mark this object as resolved to avoid more future resolves
-m_is_resolved = (m_directory == resolved_lhs.m_directory);
-}
-else
-return false;
+// This path wasn't resolved but now it is. Check if the resolved
+// directory is the same as our unresolved directory, and if so,
+// we can mark this object as resolved to avoid more future resolves
+m_is_resolved = (m_directory == resolved_lhs.m_directory);
}
-
-FileSpec resolved_rhs(rhs);
-if (!rhs.IsResolved())
+else
+return false;
+}
+
+FileSpec resolved_rhs(rhs);
+if (!rhs.IsResolved())
+{
+if (resolved_rhs.ResolvePath())
{
-if (resolved_rhs.ResolvePath())
-{
-// rhs's path wasn't resolved but now it is. Check if the resolved
-// directory is the same as rhs's unresolved directory, and if so,
-// we can mark this object as resolved to avoid more future resolves
-rhs.m_is_resolved = (rhs.m_directory == resolved_rhs.m_directory);
-}
-else
-return false;
+// rhs's path wasn't resolved but now it is. Check if the resolved
+// directory is the same as rhs's unresolved directory, and if so,
+// we can mark this object as resolved to avoid more future resolves
+rhs.m_is_resolved = (rhs.m_directory == resolved_rhs.m_directory);
}
-
-// If we reach this point in the code we were able to resolve both paths
-// and since we only resolve the paths if the basenames are equal, then
-// we can just check if both directories are equal...
-return resolved_lhs.GetDirectory() == resolved_rhs.GetDirectory();
+else
+return false;
}
-return false;
+
+// If we reach
[Lldb-commits] [lldb] r261716 - Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes.
Author: eugenezelenko
Date: Tue Feb 23 20:05:55 2016
New Revision: 261716
URL: http://llvm.org/viewvc/llvm-project?rev=261716&view=rev
Log:
Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some
files in source/Commands; other minor fixes.
Modified:
lldb/trunk/source/Commands/CommandObjectSettings.cpp
lldb/trunk/source/Commands/CommandObjectSource.cpp
lldb/trunk/source/Commands/CommandObjectWatchpoint.cpp
Modified: lldb/trunk/source/Commands/CommandObjectSettings.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectSettings.cpp?rev=261716&r1=261715&r2=261716&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectSettings.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectSettings.cpp Tue Feb 23 20:05:55
2016
@@ -12,6 +12,8 @@
// C Includes
// C++ Includes
// Other libraries and framework includes
+#include "llvm/ADT/StringRef.h"
+
// Project includes
#include "lldb/Interpreter/CommandInterpreter.h"
#include "lldb/Interpreter/CommandReturnObject.h"
@@ -20,7 +22,6 @@
using namespace lldb;
using namespace lldb_private;
-#include "llvm/ADT/StringRef.h"
//-
// CommandObjectSettingsSet
@@ -30,10 +31,10 @@ class CommandObjectSettingsSet : public
{
public:
CommandObjectSettingsSet (CommandInterpreter &interpreter) :
-CommandObjectRaw (interpreter,
- "settings set",
- "Set or change the value of a single debugger
setting variable.",
- NULL),
+CommandObjectRaw(interpreter,
+ "settings set",
+ "Set or change the value of a single debugger setting
variable.",
+ nullptr),
m_options (interpreter)
{
CommandArgumentEntry arg1;
@@ -82,8 +83,7 @@ insert-before or insert-after."
}
-
-~CommandObjectSettingsSet () override {}
+~CommandObjectSettingsSet() override = default;
// Overrides base class's behavior where WantsCompletion =
!WantsRawCommandString.
bool
@@ -98,14 +98,13 @@ insert-before or insert-after."
class CommandOptions : public Options
{
public:
-
CommandOptions (CommandInterpreter &interpreter) :
Options (interpreter),
m_global (false)
{
}
-~CommandOptions () override {}
+~CommandOptions() override = default;
Error
SetOptionValue (uint32_t option_idx, const char *option_arg) override
@@ -160,7 +159,7 @@ insert-before or insert-after."
std::string completion_str (input.GetArgumentAtIndex (cursor_index),
cursor_char_position);
const size_t argc = input.GetArgumentCount();
-const char *arg = NULL;
+const char *arg = nullptr;
int setting_var_idx;
for (setting_var_idx = 1; setting_var_idx < static_cast(argc);
++setting_var_idx)
@@ -172,14 +171,14 @@ insert-before or insert-after."
if (cursor_index == setting_var_idx)
{
// Attempting to complete setting variable name
-CommandCompletions::InvokeCommonCompletionCallbacks (m_interpreter,
-
CommandCompletions::eSettingsNameCompletion,
-
completion_str.c_str(),
-
match_start_point,
-
max_return_elements,
- NULL,
- word_complete,
- matches);
+CommandCompletions::InvokeCommonCompletionCallbacks(m_interpreter,
+
CommandCompletions::eSettingsNameCompletion,
+
completion_str.c_str(),
+
match_start_point,
+
max_return_elements,
+nullptr,
+word_complete,
+matches);
}
else
{
@@ -231,7 +230,7 @@ protected:
}
const char *var_name = cmd_args.GetArgumentAtIndex (0);
-if ((var_name == NULL) || (var_name[0] == '\0'))
+if ((var_name == nullptr) || (var_name[0] == '\0'))
{
result.AppendError ("'settings set' command requires a valid
v
Re: [Lldb-commits] [PATCH] D17492: Case sensitive path compare on Windows breaks breakpoints
Honsik added inline comments.
Comment at: packages/Python/lldbsuite/test/dotest.py:288-294
@@ -288,1 +287,9 @@
+
+if sys.platform.startswith('win32'):
+import ctypes, time
+while not ctypes.windll.kernel32.IsDebuggerPresent():
+time.sleep(0.5)
+ctypes.windll.kernel32.DebugBreak()
+else:
+os.kill(os.getpid(), signal.SIGSTOP)
zturner wrote:
> See if you can get [[ https://github.com/Microsoft/PTVS/releases | PTVS ]] to
> work. If so, you won't need any of this code and it will be a much better
> debugging experience anyway. Assuming PTVS works for you, I'd rather just
> delete this code. I'm planning to add info about using PTVS to the website
> this week.
>
>
Ok I removed this part, it is working using PTVS. But maybe in future we will
still need something similar if we would like to debug lldb testsuite using
lldb, because I don't know whether lldb will support Python in near future. We
can always return this part back.
http://reviews.llvm.org/D17492
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D17557: Fix TestCStrings for Linux with i386 inferiors.
This revision was automatically updated to reflect the committed changes.
Closed by commit rL261718: Fix TestCStrings for Linux with i386 inferiors.
(authored by chaoren).
Changed prior to commit:
http://reviews.llvm.org/D17557?vs=48867&id=48878#toc
Repository:
rL LLVM
http://reviews.llvm.org/D17557
Files:
lldb/trunk/source/Expression/IRExecutionUnit.cpp
Index: lldb/trunk/source/Expression/IRExecutionUnit.cpp
===
--- lldb/trunk/source/Expression/IRExecutionUnit.cpp
+++ lldb/trunk/source/Expression/IRExecutionUnit.cpp
@@ -213,7 +213,7 @@
InstructionList &instruction_list = disassembler_sp->GetInstructionList();
instruction_list.Dump(&stream, true, true, &exe_ctx);
-
+
// FIXME: The DisassemblerLLVMC has a reference cycle and won't go away if it has any active instructions.
// I'll fix that but for now, just clear the list and it will go away nicely.
disassembler_sp->GetInstructionList().Clear();
@@ -297,7 +297,7 @@
{
relocModel = llvm::Reloc::PIC_;
}
-
+
// This will be small for 32-bit and large for 64-bit.
codeModel = llvm::CodeModel::JITDefault;
@@ -325,7 +325,7 @@
mAttrs);
m_execution_engine_ap.reset(builder.create(target_machine));
-
+
m_strip_underscore = (m_execution_engine_ap->getDataLayout().getGlobalPrefix() == '_');
if (!m_execution_engine_ap.get())
@@ -373,27 +373,27 @@
if (m_failed_lookups.size())
{
StreamString ss;
-
+
ss.PutCString("Couldn't lookup symbols:\n");
-
+
bool emitNewLine = false;
-
+
for (const ConstString &failed_lookup : m_failed_lookups)
{
if (emitNewLine)
ss.PutCString("\n");
emitNewLine = true;
ss.PutCString(" ");
ss.PutCString(Mangled(failed_lookup).GetDemangledName(lldb::eLanguageTypeObjC_plus_plus).AsCString());
}
-
+
m_failed_lookups.clear();
-
+
error.SetErrorString(ss.GetData());
-
+
return;
}
-
+
m_function_load_addr = LLDB_INVALID_ADDRESS;
m_function_end_load_addr = LLDB_INVALID_ADDRESS;
@@ -446,7 +446,7 @@
else
{
record.dump(log);
-
+
DataExtractor my_extractor ((const void*)record.m_host_address, record.m_size, lldb::eByteOrderBig, 8);
my_extractor.PutToLog(log, 0, record.m_size, record.m_host_address, 16, DataExtractor::TypeUInt8);
}
@@ -731,29 +731,29 @@
{
Mangled mangled(name, true);
ConstString demangled = mangled.GetDemangledName(lldb::eLanguageTypeC_plus_plus);
-
+
if (demangled)
{
ConstString best_alternate_mangled_name = FindBestAlternateMangledName(demangled, lldb::eLanguageTypeC_plus_plus, sc);
-
+
if (best_alternate_mangled_name)
{
CPP_specs.push_back(best_alternate_mangled_name);
}
-
+
CPP_specs.push_back(SearchSpec(demangled, lldb::eFunctionNameTypeFull));
}
}
-
+
// Maybe we're looking for a const symbol but the debug info told us it was const...
if (!strncmp(name.GetCString(), "_ZN", 3) &&
strncmp(name.GetCString(), "_ZNK", 4))
{
std::string fixed_scratch("_ZNK");
fixed_scratch.append(name.GetCString() + 3);
CPP_specs.push_back(ConstString(fixed_scratch.c_str()));
}
-
+
// Maybe we're looking for a static symbol but we thought it was global...
if (!strncmp(name.GetCString(), "_Z", 2) &&
strncmp(name.GetCString(), "_ZL", 3))
@@ -799,33 +799,28 @@
const bool is_external = (candidate_sc.function) ||
(candidate_sc.symbol && candidate_sc.symbol->IsExternal());
-AddressRange range;
+load_address = candidate_sc.symbol->ResolveCallableAddress(*target);
-if (candidate_sc.GetAddressRange(lldb::eSymbolContextFunction | lldb::eSymbolContextSymbol,
- 0,
- false,
- range))
-{
-load_address = range.GetBaseAddress().GetCallableLoadAddress(target);
+if (load_address == LLDB_INVALID_ADDRESS)
+load_address = candidate_sc.symbol->GetAddress().GetLoadAddress(target);
-if (load_address != LLDB_INVALID_ADDRESS)
+if (load_address != LLDB_INVALID_ADDRESS)
+{
+if (is_e
[Lldb-commits] [lldb] r261718 - Fix TestCStrings for Linux with i386 inferiors.
Author: chaoren
Date: Tue Feb 23 21:15:21 2016
New Revision: 261718
URL: http://llvm.org/viewvc/llvm-project?rev=261718&view=rev
Log:
Fix TestCStrings for Linux with i386 inferiors.
Summary: Temporarily revert part of r261704.
Reviewers: spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17557
Modified:
lldb/trunk/source/Expression/IRExecutionUnit.cpp
Modified: lldb/trunk/source/Expression/IRExecutionUnit.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/IRExecutionUnit.cpp?rev=261718&r1=261717&r2=261718&view=diff
==
--- lldb/trunk/source/Expression/IRExecutionUnit.cpp (original)
+++ lldb/trunk/source/Expression/IRExecutionUnit.cpp Tue Feb 23 21:15:21 2016
@@ -213,7 +213,7 @@ IRExecutionUnit::DisassembleFunction (St
InstructionList &instruction_list = disassembler_sp->GetInstructionList();
instruction_list.Dump(&stream, true, true, &exe_ctx);
-
+
// FIXME: The DisassemblerLLVMC has a reference cycle and won't go away if
it has any active instructions.
// I'll fix that but for now, just clear the list and it will go away
nicely.
disassembler_sp->GetInstructionList().Clear();
@@ -297,7 +297,7 @@ IRExecutionUnit::GetRunnableInfo(Error &
{
relocModel = llvm::Reloc::PIC_;
}
-
+
// This will be small for 32-bit and large for 64-bit.
codeModel = llvm::CodeModel::JITDefault;
@@ -325,7 +325,7 @@ IRExecutionUnit::GetRunnableInfo(Error &
mAttrs);
m_execution_engine_ap.reset(builder.create(target_machine));
-
+
m_strip_underscore =
(m_execution_engine_ap->getDataLayout().getGlobalPrefix() == '_');
if (!m_execution_engine_ap.get())
@@ -373,11 +373,11 @@ IRExecutionUnit::GetRunnableInfo(Error &
if (m_failed_lookups.size())
{
StreamString ss;
-
+
ss.PutCString("Couldn't lookup symbols:\n");
-
+
bool emitNewLine = false;
-
+
for (const ConstString &failed_lookup : m_failed_lookups)
{
if (emitNewLine)
@@ -386,14 +386,14 @@ IRExecutionUnit::GetRunnableInfo(Error &
ss.PutCString(" ");
ss.PutCString(Mangled(failed_lookup).GetDemangledName(lldb::eLanguageTypeObjC_plus_plus).AsCString());
}
-
+
m_failed_lookups.clear();
-
+
error.SetErrorString(ss.GetData());
-
+
return;
}
-
+
m_function_load_addr = LLDB_INVALID_ADDRESS;
m_function_end_load_addr = LLDB_INVALID_ADDRESS;
@@ -446,7 +446,7 @@ IRExecutionUnit::GetRunnableInfo(Error &
else
{
record.dump(log);
-
+
DataExtractor my_extractor ((const
void*)record.m_host_address, record.m_size, lldb::eByteOrderBig, 8);
my_extractor.PutToLog(log, 0, record.m_size,
record.m_host_address, 16, DataExtractor::TypeUInt8);
}
@@ -731,20 +731,20 @@ IRExecutionUnit::CollectCandidateCPlusPl
{
Mangled mangled(name, true);
ConstString demangled =
mangled.GetDemangledName(lldb::eLanguageTypeC_plus_plus);
-
+
if (demangled)
{
ConstString best_alternate_mangled_name =
FindBestAlternateMangledName(demangled, lldb::eLanguageTypeC_plus_plus, sc);
-
+
if (best_alternate_mangled_name)
{
CPP_specs.push_back(best_alternate_mangled_name);
}
-
+
CPP_specs.push_back(SearchSpec(demangled,
lldb::eFunctionNameTypeFull));
}
}
-
+
// Maybe we're looking for a const symbol but the debug info told us
it was const...
if (!strncmp(name.GetCString(), "_ZN", 3) &&
strncmp(name.GetCString(), "_ZNK", 4))
@@ -753,7 +753,7 @@ IRExecutionUnit::CollectCandidateCPlusPl
fixed_scratch.append(name.GetCString() + 3);
CPP_specs.push_back(ConstString(fixed_scratch.c_str()));
}
-
+
// Maybe we're looking for a static symbol but we thought it was
global...
if (!strncmp(name.GetCString(), "_Z", 2) &&
strncmp(name.GetCString(), "_ZL", 3))
@@ -799,33 +799,28 @@ IRExecutionUnit::FindInSymbols(const std
const bool is_external = (candidate_sc.function) ||
(candidate_sc.symbol &&
candidate_sc.symbol->IsExternal());
-AddressRange range;
+load_address =
candidate_sc.symbol->ResolveCallableAddress(*target);
-if (candidate_sc.GetAddressRange(lldb::eSymbolContextFunction
| lldb::eSymbolContextSymbol,
- 0,
-
Re: [Lldb-commits] [PATCH] D17492: Case sensitive path compare on Windows breaks breakpoints
zturner added inline comments. Comment at: source/Host/common/FileSpec.cpp:519 @@ -515,3 +518,3 @@ // in one of the FileSpec objects. if (full || (a.m_directory && b.m_directory)) Did the case sensitive check get removed here? I thought this would need to be ``` result = ConstString::Compare(a.m_directory, b.m_directory, a.IsCaseSensitive() || b.IsCaseSensitive()); ``` The same later in this function, and also for `FileSpec::Equal` http://reviews.llvm.org/D17492 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D17492: Case sensitive path compare on Windows breaks breakpoints
zturner accepted this revision. zturner added a comment. This revision is now accepted and ready to land. Looks good after the fix of the misspelling. If you want I can fix it for you and commit tomorrow. I assume you ran the test suite and did not see any new errors? Comment at: source/Host/common/FileSpec.cpp:535 @@ +534,3 @@ +// case sensitivity of equality test +const bool case_sentitive = a.IsCaseSensitive() || b.IsCaseSensitive(); + Minor nitpick, you misspelled `case_sensitive` as `case_sentitive`. http://reviews.llvm.org/D17492 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
