aboutsummaryrefslogtreecommitdiff
path: root/libctf
diff options
context:
space:
mode:
authorNick Alcock <nick.alcock@oracle.com>2020-07-01 20:10:17 +0100
committerNick Alcock <nick.alcock@oracle.com>2020-07-22 18:05:32 +0100
commit4533ed564d6953990210ba63c091009380ec2327 (patch)
treefad001573ba50372fe46ab53d9079895636e6519 /libctf
parent62cdd7b18fc41a29b6bc22b4bbba0bff55434628 (diff)
downloadgdb-4533ed564d6953990210ba63c091009380ec2327.zip
gdb-4533ed564d6953990210ba63c091009380ec2327.tar.gz
gdb-4533ed564d6953990210ba63c091009380ec2327.tar.bz2
libctf, binutils: fix big-endian libctf archive opening
The recent commit "libctf, binutils: support CTF archives like objdump" broke opening of CTF archives on big-endian platforms. This didn't affect anyone much before now because the linker never emitted CTF archives because it wasn't detecting ambiguous types properly: now it does, and this bug becomes obvious. Fix trivial. libctf/ * ctf-archive.c (ctf_arc_bufopen): Endian-swap the archive magic number if needed.
Diffstat (limited to 'libctf')
-rw-r--r--libctf/ChangeLog5
-rw-r--r--libctf/ctf-archive.c2
2 files changed, 6 insertions, 1 deletions
diff --git a/libctf/ChangeLog b/libctf/ChangeLog
index 803e8de..cfb9d01 100644
--- a/libctf/ChangeLog
+++ b/libctf/ChangeLog
@@ -1,5 +1,10 @@
2020-07-22 Nick Alcock <nick.alcock@oracle.com>
+ * ctf-archive.c (ctf_arc_bufopen): Endian-swap the archive magic
+ number if needed.
+
+2020-07-22 Nick Alcock <nick.alcock@oracle.com>
+
* ctf-impl.h (ctf_list_splice): New.
* ctf-util.h (ctf_list_splice): Likewise.
* ctf-link.c (link_sort_inputs_cb_arg_t): Likewise.
diff --git a/libctf/ctf-archive.c b/libctf/ctf-archive.c
index 4578552..87e682c 100644
--- a/libctf/ctf-archive.c
+++ b/libctf/ctf-archive.c
@@ -386,7 +386,7 @@ ctf_arc_bufopen (const ctf_sect_t *ctfsect, const ctf_sect_t *symsect,
ctf_file_t *fp = NULL;
if (ctfsect->cts_size > sizeof (uint64_t) &&
- ((*(uint64_t *) ctfsect->cts_data) == CTFA_MAGIC))
+ (le64toh ((*(uint64_t *) ctfsect->cts_data)) == CTFA_MAGIC))
{
/* The archive is mmappable, so this operation is trivial.