Summary: | Warning messages from libraries with Valgrind 3.7.0 | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Aneesh <aneesh.bansal> |
Component: | memcheck | Assignee: | Julian Seward <jseward> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | aneesh.bansal, erwin.rieger, magnus.olov.andersson, per.dalen, vakul |
Priority: | NOR | ||
Version: | 3.7.0 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | Simple Hello World Application Program |
Got the same error ("Serious error when reading debug info...") with valgrind trunk (rev. 12379) on a PPC host (PPC440EPx, ELDK4.2). No symbols get loaded. Don't know if its a valgrind or a linker/toolchain/binutils error. It boils down to a loop in readelf.c:read_elf_debug_info(). There it is not able to detect a "RW Area". The test statement is: "(phdr->p_flags & (PF_R | PF_W | PF_X)) == (PF_R | PF_W)". In this particular case the Read, Write AND Execute bits are set and the statement evaluates to false... As a workaround i've applied this patch: ########################### snip ########################## --- coregrind/m_debuginfo/readelf.c (Revision 12379) +++ coregrind/m_debuginfo/readelf.c (Arbeitskopie) @@ -1539,7 +1539,7 @@ && phdr->p_offset < di->fsm.rw_map_foff + di->fsm.rw_map_size && phdr->p_offset + phdr->p_filesz <= di->fsm.rw_map_foff + di->fsm.rw_map_size - && (phdr->p_flags & (PF_R | PF_W | PF_X)) == (PF_R | PF_W)) { + && (phdr->p_flags & (PF_R | PF_W | PF_X)) >= (PF_R | PF_W)) { if (n_rw == N_RX_RW_AREAS) { ML_(symerr)(di, True, "N_RX_RW_AREAS is too low; " ########################### snip ########################## Valgrind is now able to read the symbols from the programms and libraries. The relevant snippet from readelf output of the to-be-debuged program: ########################### snip ########################## ELF Header: Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: PowerPC Version: 0x1 Entry point address: 0x10000550 Start of program headers: 52 (bytes into file) Start of section headers: 39416 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 8 Size of section headers: 40 (bytes) Number of section headers: 38 Section header string table index: 35 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .interp PROGBITS 10000134 000134 00000d 00 A 0 0 1 [ 2] .note.ABI-tag NOTE 10000144 000144 000020 00 A 0 0 4 ... [19] .got2 PROGBITS 10041018 001018 000008 00 WA 0 0 1 [20] .dynamic DYNAMIC 10041020 001020 0000d8 08 WA 5 0 4 [21] .data PROGBITS 100410f8 0010f8 000008 00 WA 0 0 4 [22] .got PROGBITS 10041100 001100 000014 04 WAX 0 0 4 [23] .sbss NOBITS 10041114 001114 000006 00 WA 0 0 4 ... [37] .strtab STRTAB 00000000 00aca8 000950 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) There are no section groups in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x10000034 0x10000034 0x00100 0x00100 R E 0x4 INTERP 0x000134 0x10000134 0x10000134 0x0000d 0x0000d R 0x1 [Requesting program interpreter: /lib/ld.so.1] LOAD 0x000000 0x10000000 0x10000000 0x00f98 0x00f98 R E 0x40000 LOAD 0x001000 0x10041000 0x10041000 0x00114 0x00204 RWE 0x40000 DYNAMIC 0x001020 0x10041020 0x10041020 0x000d8 0x000d8 RW 0x4 NOTE 0x000144 0x10000144 0x10000144 0x00020 0x00020 R 0x4 GNU_EH_FRAME 0x000e78 0x10000e78 0x10000e78 0x0003c 0x0003c R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4 ########################### snip ########################## As you can see, the program header 4 at position 0x001000 has the flags "RWE". Let me know, if you need more info ... I confirm the patch fixes the same bug I had using valgrind on a e300c3 (powerpc) compiler. Can you try 3.8.0 and see if the problem still exists? I believe this may have been fixed with a more general patch in 3.8.0, but I am not sure. Hi, does Valgrind 3.8.0 or 3.8.1 have this patch (I looked in release notes for both but didn't see anything that looked like solving this bug?)?? Otherwise, does anybody know if this problem occured first in 3.7.0 and didn't exist in earlier releases? I have tested vanilla Valgrind 3.8.1 for e300c3 (powerpc) compiler and it works fine without any patch. (In reply to comment #4) > Hi, does Valgrind 3.8.0 or 3.8.1 have this patch (I looked in release notes > for both but didn't see anything that looked like solving this bug?)?? > > Otherwise, does anybody know if this problem occured first in 3.7.0 and > didn't exist in earlier releases? |
Created attachment 67213 [details] Simple Hello World Application Program I am getting the following warning messages when running a Simple Hello World Application with Valgrind 3.7.0. CPU : PowerPC e500mc ==2303== Memcheck, a memory error detector ==2303== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==2303== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==2303== Command: ./hello ==2303== --2303-- WARNING: Serious error when reading debug info --2303-- When reading debug info from /lib/ld-2.13.so: --2303-- Can't make sense of .got section mapping --2303-- WARNING: Serious error when reading debug info --2303-- When reading debug info from /usr/lib/valgrind/vgpreload_core-ppc32-linux.so: --2303-- Can't make sense of .data section mapping --2303-- WARNING: Serious error when reading debug info --2303-- When reading debug info from /usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so: --2303-- Can't make sense of .data section mapping --2303-- WARNING: Serious error when reading debug info --2303-- When reading debug info from /lib/libc-2.13.so: --2303-- Can't make sense of .data section mapping Hello... Testing Valgrind ==2303== ==2303== HEAP SUMMARY: ==2303== in use at exit: 0 bytes in 0 blocks ==2303== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==2303== ==2303== All heap blocks were freed -- no leaks are possible ==2303== ==2303== For counts of detected and suppressed errors, rerun with: -v ==2303== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)