Roland McGrath <roland(a)hack.frob.com> writes:
ARM doesn't seem to be covered in run-allregs.sh, so that should
be
fixed too.
I added that test now.
When posting such a change, it's nice to show the readelf -n
output
generated.
With FPREGSET_SIZE changed to 116 and VFP code in, the output is as
follows:
Note segment of 892 bytes at offset 0x2f4:
Owner Data size Type
CORE 148 PRSTATUS
info.si_signo: 11, info.si_code: 0, info.si_errno: 0, cursig: 11
sigpend: <>
sighold: <>
pid: 12331, ppid: 12308, pgrp: 12331, sid: 12283
utime: 0.000000, stime: 0.000000, cutime: 0.000000, cstime: 0.000000
orig_r0: -1093634896, fpvalid: 1
r0: -4 r1: 0 r2: 0
r3: 16 r4: -1225779488 r5: 0
r6: 2 r7: 162 r8: 38760
r9: 50432 r10: 1 r11: 0
r12: 0 sp: 0xbed074ac lr: 0x0000b904
pc: 0xb6df1dac spsr: 0x60000010
CORE 124 PRPSINFO
state: 0, sname: R, zomb: 0, nice: 0, flag: 0x00400400
uid: 500, gid: 500, pid: 12331, ppid: 12308, pgrp: 12331, sid: 12283
fname: sleep, psargs: sleep 100
CORE 144 AUXV
HWCAP: 0xb8d7 <swp half thumb fast-mult vfp edsp>
PAGESZ: 4096
CLKTCK: 100
PHDR: 0x8034
PHENT: 32
PHNUM: 9
BASE: 0xb6ede000
FLAGS: 0
ENTRY: 0x9410
UID: 500
EUID: 500
GID: 500
EGID: 500
SECURE: 0
RANDOM: 0xbed07763
EXECFN: 0xbed07ff1
PLATFORM: 0xbed07773
NULL
CORE 116 FPREGSET
f0: 0x000000000000000000000000 f1: 0x000000000000000000000000
f2: 0x000000000000000000000000 f3: 0x000000000000000000000000
f4: 0x000000000000000000000000 f5: 0x000000000000000000000000
f6: 0x000000000000000000000000 f7: 0x000000000000000000000000
LINUX 260 ARM_VFP
d0: 0x0000000000000000 d1: 0x0000000000000000
d2: 0x0000000000000000 d3: 0x0000000000000000
d4: 0x0000000000000000 d5: 0x0000000100000000
d6: 0x0000006400000000 d7: 0x0000000000000000
d8: 0x4059000000000000 d9: 0x0000000000000000
d10: 0x0000000000000000 d11: 0x0000000000000000
d12: 0x0000000000000000 d13: 0x0000000000000000
d14: 0x0000000000000000 d15: 0x0000000000000000
d16: 0x0000000000000000 d17: 0x0000000000000000
d18: 0x0000000000000000 d19: 0x0000000000000000
d20: 0x0000000000000000 d21: 0x0000000000000000
d22: 0x0000000000000000 d23: 0x0000000000000000
d24: 0x0000000000000000 d25: 0x0000000000000000
d26: 0x0000000000000000 d27: 0x0000000000000000
d28: 0x0000000000000000 d29: 0x0000000000000000
d30: 0x0000000000000000 d31: 0x0000000000000000
You can describe the fpscr slot with Ebl_Core_Item, similar to how
i386_corenote.c handles "orig_eax".
When I do this, it hits a bug in readelf, in handle_core_items. If a
core note contains both registers and items, descsz is 0 to express that
we don't wish to repeat the items. If there is only one item in such
note, a special block of code hits that passes &size (size_t size =
descsz;) to handle_core_item, which will decrease that size by the
amount consumed by the item. But because size is 0, it underflows and
wraps, and the loop following this block, which handles the common case,
overruns the core note buffer. One way to fix this is as follows:
--- a/src/readelf.c
+++ b/src/readelf.c
@@ -7699,7 +7699,11 @@ handle_core_items (Elf *core, const void *desc, size_t descsz,
if (nitems == 1)
{
size_t size = descsz;
- colno = handle_core_item (core, sorted_items[0], desc, colno, &size);
+ /* If this note contains registers as well as items, don't pass
+ &size to express that we don't wish to repeat. */
+ colno = handle_core_item (core, sorted_items[0], desc, colno,
+ size != 0 ? &size : NULL);
+
if (size == 0)
return colno;
desc += descsz - size;
Another way to fix this is to simply remove the whole block
special-casing singleton item. The general code handles the case of
nitems == 1 just fine, it looks like that block is simply an
optimization.
What say you?
Thanks,
PM