Re: [Lldb-commits] [PATCH] D16508: NetBSD: Define initial RegisterContextNetBSD_x86_64
krytarowski updated this revision to Diff 46489.
krytarowski added a comment.
Revamped version.
Changes:
- change type of registers from int64_t to uint64_t,
- remove unsupported debug x86 registers,
- model UserArea after mcontext_t
Patch building tested.
Repository:
rL LLVM
http://reviews.llvm.org/D16508
Files:
source/Plugins/Process/Utility/CMakeLists.txt
source/Plugins/Process/Utility/RegisterContextNetBSD_x86_64.cpp
source/Plugins/Process/Utility/RegisterContextNetBSD_x86_64.h
Index: source/Plugins/Process/Utility/RegisterContextNetBSD_x86_64.h
===
--- /dev/null
+++ source/Plugins/Process/Utility/RegisterContextNetBSD_x86_64.h
@@ -0,0 +1,35 @@
+//===-- RegisterContextNetBSD_x86_64.h -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef liblldb_RegisterContextNetBSD_x86_64_H_
+#define liblldb_RegisterContextNetBSD_x86_64_H_
+
+#include "RegisterInfoInterface.h"
+
+class RegisterContextNetBSD_x86_64:
+public lldb_private::RegisterInfoInterface
+{
+public:
+RegisterContextNetBSD_x86_64(const lldb_private::ArchSpec &target_arch);
+
+size_t
+GetGPRSize() const override;
+
+const lldb_private::RegisterInfo *
+GetRegisterInfo() const override;
+
+uint32_t
+GetRegisterCount () const override;
+
+private:
+const lldb_private::RegisterInfo *m_register_info_p;
+const uint32_t m_register_count;
+};
+
+#endif
Index: source/Plugins/Process/Utility/RegisterContextNetBSD_x86_64.cpp
===
--- /dev/null
+++ source/Plugins/Process/Utility/RegisterContextNetBSD_x86_64.cpp
@@ -0,0 +1,364 @@
+//===-- RegisterContextNetBSD_x86_64.cpp --*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===-===//
+
+#include
+#include
+
+#include "llvm/Support/Compiler.h"
+
+#include "RegisterContextPOSIX_x86.h"
+#include "RegisterContextNetBSD_x86_64.h"
+
+using namespace lldb_private;
+using namespace lldb;
+
+// src/sys/arch/amd64/include/frame_regs.h
+typedef struct _GPR
+{
+uint64_t rdi; /* 0 */
+uint64_t rsi; /* 1 */
+uint64_t rdx; /* 2 */
+uint64_t rcx; /* 3 */
+uint64_t r8; /* 4 */
+uint64_t r9; /* 5 */
+uint64_t r10; /* 6 */
+uint64_t r11; /* 7 */
+uint64_t r12; /* 8 */
+uint64_t r13; /* 9 */
+uint64_t r14; /* 10 */
+uint64_t r15; /* 11 */
+uint64_t rbp; /* 12 */
+uint64_t rbx; /* 13 */
+uint64_t rax; /* 14 */
+uint64_t gs; /* 15 */
+uint64_t fs; /* 16 */
+uint64_t es; /* 17 */
+uint64_t ds; /* 18 */
+uint64_t trapno; /* 19 */
+uint64_t err; /* 20 */
+uint64_t rip; /* 21 */
+uint64_t cs; /* 22 */
+uint64_t rflags; /* 23 */
+uint64_t rsp; /* 24 */
+uint64_t ss; /* 25 */
+} GPR;
+
+/*
+ * As of NetBSD-7.99.25 there is no support for debug registers
+ * https://en.wikipedia.org/wiki/X86_debug_register
+ */
+
+/*
+ * src/sys/arch/amd64/include/mcontext.h
+ *
+ * typedef struct {
+ * __gregset_t __gregs;
+ * __greg_t_mc_tlsbase;
+ * __fpregset_t__fpregs;
+ * } mcontext_t;
+ */
+
+struct UserArea {
+GPR gpr;
+uint64_t mc_tlsbase;
+FPR fpr;
+};
+
+
+//---
+// Cherry-pick parts of RegisterInfos_x86_64.h, without debug registers
+//---
+// Computes the offset of the given GPR in the user data area.
+#define GPR_OFFSET(regname) \
+(LLVM_EXTENSION offsetof(GPR, regname))
+
+// Computes the offset of the given FPR in the extended data area.
+#define FPR_OFFSET(regname) \
+(LLVM_EXTENSION offsetof(UserArea, fpr) + \
+ LLVM_EXTENSION offsetof(FPR, xstate) + \
+ LLVM_EXTENSION offsetof(FXSAVE, regname))
+
+// Computes the offset of the YMM register assembled from register halves.
+// Based on DNBArchImplX86_64.cpp from debugserver
+#define YMM_OFFSET(reg_index) \
+(LLVM_EXTENSION offsetof(UserArea, fpr) + \
+ LLVM_EXTENSION offsetof(FPR, xstate) + \
+ LLVM_EXTENSION offsetof(XSAVE, ymmh[0]) + \
+ (32 * reg_index))
+
+// Number of bytes needed to represent a FPR.
+#define FPR_SIZE(reg) sizeof(((FXSAVE*)NULL)->reg)
+
+// Number of bytes needed to represent the i'th FP register.
+#define FP_SIZE sizeof(((MMSReg*)NULL)->bytes)
+
+
Re: [Lldb-commits] [PATCH] D16508: NetBSD: Define initial RegisterContextNetBSD_x86_64
krytarowski added a comment. Please review. I'm still unsure whether `FPR fpr` will be fine. Repository: rL LLVM http://reviews.llvm.org/D16508 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16736: Always write the session log file in UTF-8
tfiala added a comment. In http://reviews.llvm.org/D16736#339925, @tfiala wrote: > In http://reviews.llvm.org/D16736#339889, @zturner wrote: > > > Hmm, that almost looks to me like it's finding a real bug. Which it > > probably is, because higher up the callstack it's reading the response of a > > memory send. I'm guessing that the response includes non-printable > > characters (raw memory data) that wasn't being written before but was being > > silently ignored, and now it's giving an error. > > > > Can you try passing errors='replace' to encoded_file.open()? Then open the > > log file and see what's in it. > > > Yep, I can give that a try. It'll end up being later (not at a computer now) > but I'll give it a shot. I'm going to have a look at trying this modification now. http://reviews.llvm.org/D16736 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16736: Always write the session log file in UTF-8
tfiala added a comment.
> I'm going to have a look at trying this modification now.
I'm getting the same error with the replace.
Here is the patch (okay the whole encoded_file.py) I was able to use to get
past this - which ultimately looks to be an error in the match result printing
of a raw byte buffer (never meant to be unicode printable) in the result stream
(i.e. the error I was getting looked to be purely a by-product of printing
match results that succeeded, not failed, but the unicode decoding introduced
the actual failure point):
"""
The LLVM Compiler Infrastructure
This file is distributed under the University of Illinois Open Source
License. See LICENSE.TXT for details.
Prepares language bindings for LLDB build process. Run with --help
to see a description of the supported command line arguments.
"""
# Python modules:
import io
# Third party modules
import six
def _encoded_read(old_read, encoding):
def impl(size):
result = old_read(size)
# If this is Python 2 then we need to convert the resulting `unicode`
back
# into a `str` before returning
if six.PY2:
result = result.encode(encoding)
return result
return impl
def _encoded_write(old_write, encoding):
def impl(s):
# If we were asked to write a `str` (in Py2) or a `bytes` (in Py3)
decode it
# as unicode before attempting to write.
if isinstance(s, six.binary_type):
try:
s = s.decode(encoding)
except UnicodeDecodeError as decode_err:
import sys
sys.stderr.write("error: unicode decode failed on raw string
'{}': '{}'".format(s, decode_err))
s = u"Could not decode unicode string, see stderr for details"
return old_write(s)
return impl
'''
Create a Text I/O file object that can be written to with either unicode
strings or byte strings
under Python 2 and Python 3, and automatically encodes and decodes as
necessary to return the
native string type for the current Python version
'''
def open(file, encoding, mode='r', buffering=-1, errors=None, newline=None,
closefd=True):
wrapped_file = io.open(file, mode=mode, buffering=buffering,
encoding=encoding,
errors=errors, newline=newline, closefd=closefd)
new_read = _encoded_read(getattr(wrapped_file, 'read'), encoding)
new_write = _encoded_write(getattr(wrapped_file, 'write'), encoding)
setattr(wrapped_file, 'read', new_read)
setattr(wrapped_file, 'write', new_write)
return wrapped_file
It just adds a try/except block around the Unicode decode. Is is highly likely
that might not run on Python 3 - i.e. ping pong this back into a Python 3
error. I may try to bring this up on Windows to see if that does actually
happen.
In any event, the right fix here probably is to have displays of
matched/expected text for known-to-be binary data *not* try to print results in
the expect-string-match code since these are just going to have no way of being
valid. The other way to go (perhaps better) would be to put some kind of safe
wrapper around the byte compares, so that they are tested as ASCII-ified
output, or use an entirely different mechanism here.
If this works on Windows the way I fixed this up, you can go ahead and check
this in. (I no longer get failures with the code change I made above). If it
doesn't work but you can tweak that slightly, feel free to go ahead and do that
as well. In the meantime I am going to see if I can get the binary aspect of
the matching handled properly (i.e. not done as string compares). This might
be one of my tests. (It's at least in the goop of lldb-server tests that I had
written 1.5 to 2 years ago).
http://reviews.llvm.org/D16736
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16736: Always write the session log file in UTF-8
tfiala added a comment. In http://reviews.llvm.org/D16736#340302, @tfiala wrote: > In any event, the right fix here probably is to have displays of > matched/expected text for known-to-be binary data *not* try to print results > in the expect-string-match code since these are just going to have no way of > being valid. i.e. a test fix. I think we still want to keep the unicode decode guard in, as it could easily be something printing binary-based data like we had here, but the culprit under this is basically the method the test is using to verify binary data. http://reviews.llvm.org/D16736 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16736: Always write the session log file in UTF-8
tfiala added a comment.
In fact I'd say you could do this, now that I've looked at the test:
diff --git
a/packages/Python/lldbsuite/test/tools/lldb-server/TestGDBRemoteMemoryRead.py
b/packages/Python/lldbsuite/test/tools/lldb-server/TestGDBRemoteMemoryRead.py
index 7b974e5..9f80abe 100644
---
a/packages/Python/lldbsuite/test/tools/lldb-server/TestGDBRemoteMemoryRead.py
+++
b/packages/Python/lldbsuite/test/tools/lldb-server/TestGDBRemoteMemoryRead.py
@@ -34,7 +34,7 @@ class MemoryReadTestCase(TestBase):
error = lldb.SBError()
memory = process.ReadMemory(pc, size, error)
self.assertTrue(error.Success())
-self.match("process plugin packet send x%x,%x" % (pc, size),
["response:", memory])
+# self.match("process plugin packet send x%x,%x" % (pc, size),
["response:", memory])
self.match("process plugin packet send m%x,%x" % (pc, size),
["response:", binascii.hexlify(memory)])
process.Continue()
(i.e. comment out the direct memory compare with strings). That'll take a
little bit of work to re-work, but the 'm' hexlified version is sufficient for
verifying memory reads for now until we can rework the test to compare the
bytes directly instead of counting on print-style matches. You could comment
it out and file a bug on it to fix.
http://reviews.llvm.org/D16736
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
