This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add back end code for interpreting NT_ARM_VFP core note


Roland McGrath <roland@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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]