From: Mark Wielaard <mjw@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: [PATCH] libebl: Add ebl_unwind_ret_mask.
Date: Sun, 15 Jun 2014 22:21:31 +0200 [thread overview]
Message-ID: <1402863691.21102.23.camel@bordewijk.wildebeest.org> (raw)
In-Reply-To: 20140615195956.GA10001@roeckx.be
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
On Sun, 2014-06-15 at 21:59 +0200, Kurt Roeckx wrote:
> On Sun, Jun 15, 2014 at 09:27:32PM +0200, Kurt Roeckx wrote:
> >
> > I'm not sure what that code is doing there. But it seems to be
> > looking at a 64 bit core file (x86_64, arm64, s390x) and then
> > create a 64 bit pointer is trying to dereference that.
>
> That would be a pointer to a 64 bit object of course. Sparc
> probably has stricter alignment requirements than the other
> arches. I just wonder why it worked before.
Indeed. You seem to be right that we are trying to read possibly
unaligned data which would cause a bus error on sparc. There was even a
helpful FIXME in the code about it. Why we didn't see that before is a
mystery. But the attached patch should solve it. Could you test it?
Thanks,
Mark
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-libdwfl-linux-core-attach.c-handle-possible-unaligne.patch --]
[-- Type: text/x-patch, Size: 4927 bytes --]
>From 7a6d8a0e3694af48a38e0461e15fcde0a06bad58 Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mjw@redhat.com>
Date: Sun, 15 Jun 2014 22:14:04 +0200
Subject: [PATCH] libdwfl: linux-core-attach.c handle possible unaligned data access.
Use libdw/memory-access.h macros read_4ubyte_unaligned_noncvt and
read_8ubyte_unaligned_noncvt to access possibly unaligned data in
core files.
Signed-off-by: Mark Wielaard <mjw@redhat.com>
---
libdwfl/ChangeLog | 9 +++++++++
libdwfl/linux-core-attach.c | 22 +++++++++++-----------
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog
index ac92a21..f1bc1a7 100644
--- a/libdwfl/ChangeLog
+++ b/libdwfl/ChangeLog
@@ -1,3 +1,12 @@
+2014-06-15 Mark Wielaard <mjw@redhat.com>
+
+ * linux-core-attach.c (core_memory_read): Use libdw/memory-access.h
+ macros read_4ubyte_unaligned_noncvt and read_8ubyte_unaligned_noncvt
+ to read possibly unaligned data.
+ (core_next_thread): Likewise.
+ (core_set_initial_registers): Likewise.
+ (dwfl_core_file_attach): Likewise.
+
2014-06-11 Mark Wielaard <mjw@redhat.com>
* dwfl_frame.c (__libdwfl_process_free): Reset dwfl->attacherr.
diff --git a/libdwfl/linux-core-attach.c b/libdwfl/linux-core-attach.c
index 7ef3f25..5a7b3b3 100644
--- a/libdwfl/linux-core-attach.c
+++ b/libdwfl/linux-core-attach.c
@@ -30,6 +30,8 @@
#include <fcntl.h>
#include "system.h"
+#include "../libdw/memory-access.h"
+
#ifndef MIN
# define MIN(a, b) ((a) < (b) ? (a) : (b))
#endif
@@ -83,12 +85,10 @@ core_memory_read (Dwfl *dwfl, Dwarf_Addr addr, Dwarf_Word *result,
return false;
}
assert (data->d_size == bytes);
- /* FIXME: Currently any arch supported for unwinding supports
- unaligned access. */
if (bytes == 8)
- *result = *(const uint64_t *) data->d_buf;
+ *result = read_8ubyte_unaligned_noncvt (data->d_buf);
else
- *result = *(const uint32_t *) data->d_buf;
+ *result = read_4ubyte_unaligned_noncvt (data->d_buf);
return true;
}
__libdwfl_seterrno (DWFL_E_ADDR_OUTOFRANGE);
@@ -150,7 +150,7 @@ core_next_thread (Dwfl *dwfl __attribute__ ((unused)), void *dwfl_arg,
break;
if (item == items + nitems)
continue;
- uint32_t val32 = *(const uint32_t *) (desc + item->offset);
+ uint32_t val32 = read_4ubyte_unaligned_noncvt (desc + item->offset);
val32 = (elf_getident (core, NULL)[EI_DATA] == ELFDATA2MSB
? be32toh (val32) : le32toh (val32));
pid_t tid = (int32_t) val32;
@@ -201,7 +201,7 @@ core_set_initial_registers (Dwfl_Thread *thread, void *thread_arg_voidp)
assert (item < items + nitems);
pid_t tid;
{
- uint32_t val32 = *(const uint32_t *) (desc + item->offset);
+ uint32_t val32 = read_4ubyte_unaligned_noncvt (desc + item->offset);
val32 = (elf_getident (core, NULL)[EI_DATA] == ELFDATA2MSB
? be32toh (val32) : le32toh (val32));
tid = (int32_t) val32;
@@ -218,14 +218,14 @@ core_set_initial_registers (Dwfl_Thread *thread, void *thread_arg_voidp)
switch (gelf_getclass (core) == ELFCLASS32 ? 32 : 64)
{
case 32:;
- uint32_t val32 = *(const uint32_t *) (desc + item->offset);
+ uint32_t val32 = read_4ubyte_unaligned_noncvt (desc + item->offset);
val32 = (elf_getident (core, NULL)[EI_DATA] == ELFDATA2MSB
? be32toh (val32) : le32toh (val32));
/* Do a host width conversion. */
pc = val32;
break;
case 64:;
- uint64_t val64 = *(const uint64_t *) (desc + item->offset);
+ uint64_t val64 = read_8ubyte_unaligned_noncvt (desc + item->offset);
val64 = (elf_getident (core, NULL)[EI_DATA] == ELFDATA2MSB
? be64toh (val64) : le64toh (val64));
pc = val64;
@@ -259,7 +259,7 @@ core_set_initial_registers (Dwfl_Thread *thread, void *thread_arg_voidp)
switch (regloc->bits)
{
case 32:;
- uint32_t val32 = *(const uint32_t *) reg_desc;
+ uint32_t val32 = read_4ubyte_unaligned_noncvt (reg_desc);
reg_desc += sizeof val32;
val32 = (elf_getident (core, NULL)[EI_DATA] == ELFDATA2MSB
? be32toh (val32) : le32toh (val32));
@@ -267,7 +267,7 @@ core_set_initial_registers (Dwfl_Thread *thread, void *thread_arg_voidp)
val = val32;
break;
case 64:;
- uint64_t val64 = *(const uint64_t *) reg_desc;
+ uint64_t val64 = read_8ubyte_unaligned_noncvt (reg_desc);
reg_desc += sizeof val64;
val64 = (elf_getident (core, NULL)[EI_DATA] == ELFDATA2MSB
? be64toh (val64) : le64toh (val64));
@@ -392,7 +392,7 @@ dwfl_core_file_attach (Dwfl *dwfl, Elf *core)
break;
if (item == items + nitems)
continue;
- uint32_t val32 = *(const uint32_t *) (desc + item->offset);
+ uint32_t val32 = read_4ubyte_unaligned_noncvt (desc + item->offset);
val32 = (elf_getident (core, NULL)[EI_DATA] == ELFDATA2MSB
? be32toh (val32) : le32toh (val32));
pid = (int32_t) val32;
--
1.7.1
next reply other threads:[~2014-06-15 20:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-15 20:21 Mark Wielaard [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-06-17 14:50 Mark Wielaard
2014-06-17 6:56 Mark Wielaard
2014-06-16 22:23 Roland McGrath
2014-06-15 21:51 Kurt Roeckx
2014-06-15 19:59 Kurt Roeckx
2014-06-15 19:27 Kurt Roeckx
2014-06-15 18:56 Mark Wielaard
2014-06-15 18:47 Kurt Roeckx
2014-06-15 18:42 Mark Wielaard
2014-06-15 18:38 Mark Wielaard
2014-06-15 18:18 Kurt Roeckx
2014-06-15 18:08 Kurt Roeckx
2014-06-15 10:50 Mark Wielaard
2014-06-15 10:39 Kurt Roeckx
2014-06-15 10:30 Mark Wielaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1402863691.21102.23.camel@bordewijk.wildebeest.org \
--to=mjw@redhat.com \
--cc=elfutils-devel@lists.fedorahosted.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).