aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorNick Alcock <nick.alcock@oracle.com>2019-06-19 12:34:56 +0100
committerNick Alcock <nick.alcock@oracle.com>2019-06-21 13:04:02 +0100
commit7cee18263c234073bfe88cbc962b1fc68509df82 (patch)
tree4643c2301260d63c5c378c20dee26ec477044b10 /include
parentlibctf: unidentified type kinds on open are a sign of file corruption (diff)
downloadbinutils-gdb-7cee18263c234073bfe88cbc962b1fc68509df82.tar.gz
binutils-gdb-7cee18263c234073bfe88cbc962b1fc68509df82.tar.bz2
binutils-gdb-7cee18263c234073bfe88cbc962b1fc68509df82.zip
libctf: endianness fixes
Testing of the first code to generate CTF_K_SLICEs on big-endian revealed a bunch of new problems in this area. Most importantly, the trick we did earlier to avoid wasting two bytes on padding in the ctf_slice_t is best avoided: because it leads to the whole file after that point no longer being naturally aligned, all multibyte accesses from then on must use memmove() to avoid unaligned access on platforms where that is fatal. In future, this is planned, but for now we are still doing direct access in many places, so we must revert to making ctf_slice_t properly aligned for storage in an array. Rather than wasting bytes on padding, we boost the size of cts_offset and cts_bits. This is still a waste of space (we cannot have offsets or bits in bitfields > 256) but it cannot be avoided for now, and slices are not so common that this will be a serious problem. A possibly-worse endianness problem fixed at the same time involves a codepath used only for foreign-endian, uncompressed CTF files, where we were not copying the actual CTF data into the buffer, leading to libctf reading only zeroes (or, possibly, uninitialized garbage). Finally, when we read in a CTF file, we copy the header and work from the copy. We were flipping the endianness of the header copy, and of the body of the file buffer, but not of the header in the file buffer itself: so if we write the file back out again we end up with an unreadable frankenfile with header and body of different endiannesses. Fix by flipping both copies of the header. include/ * ctf.h (ctf_slice_t): Make cts_offset and cts_bits unsigned short, so following structures are properly aligned. libctf/ * ctf-open.c (get_vbytes_common): Return the new slice size. (ctf_bufopen): Flip the endianness of the CTF-section header copy. Remember to copy in the CTF data when opening an uncompressed foreign-endian CTF file. Prune useless variable manipulation.
Diffstat (limited to 'include')
-rw-r--r--include/ChangeLog5
-rw-r--r--include/ctf.h10
2 files changed, 12 insertions, 3 deletions
diff --git a/include/ChangeLog b/include/ChangeLog
index 8169b6aae34..81b66706685 100644
--- a/include/ChangeLog
+++ b/include/ChangeLog
@@ -1,3 +1,8 @@
+2019-06-19 Nick Alcock <nick.alcock@oracle.com>
+
+ * ctf.h (ctf_slice_t): Make cts_offset and cts_bits unsigned
+ short, so following structures are properly aligned.
+
2019-06-14 Szabolcs Nagy <szabolcs.nagy@arm.com>
* elf/aarch64.h (R_AARCH64_P32_MOVW_PREL_G0): Define.
diff --git a/include/ctf.h b/include/ctf.h
index e99a673109c..2b357816baf 100644
--- a/include/ctf.h
+++ b/include/ctf.h
@@ -430,13 +430,17 @@ union
ctt_type, which must be a type which has an encoding (fp, int, or enum). We
also store the referenced type in here, because it is easier to keep the
ctt_size correct for the slice than to shuffle the size into here and keep
- the ctt_type where it is for other types. */
+ the ctt_type where it is for other types.
+
+ In a future version, where we loosen requirements on alignment in the CTF
+ file, the cts_offset and cts_bits will be chars: but for now they must be
+ shorts or everything after a slice will become unaligned. */
typedef struct ctf_slice
{
uint32_t cts_type;
- unsigned char cts_offset;
- unsigned char cts_bits;
+ unsigned short cts_offset;
+ unsigned short cts_bits;
} ctf_slice_t;
typedef struct ctf_array_v1