Menu
▾
▴
valgrind-users
|
From: Wickham, M. <Mar...@di...> - 2011-09-20 23:30:41
|
Hello,
First, I would like to thank all of the developers of valgrind for their excellent work on this most useful developer tool, and also for the recent addition of ARM support.
To that end, I have been working on valgrind 3.6.1 support for armv5 - specifically, the arm926ej-s core.
I have some patches (aka kludges) to get it to mostly run on this processor, using arm-unknown-linux-gnueabi-gcc which I am willing to share if anyone is interested, but they are not ready for prime time.
I am having an issue with the loading of the debug symbols. The GCC version I am using is 4.4.6.
I start with a very simple hello.c program, with one unfreed 8K item for testing:
#include <stdlib.h>
#include <stdio.h>
int main()
{
char *m = malloc(8192);
(void)m;
printf("Hello!\n");
exit(0);
}
$ arm-linux-gcc -W -Wall -gdwarf-2 hello.c -o hello
I am not sure how to find out which dwarf version is being compiled into my shared objects, but a sample run with the reported WARNINGS follows.
Note that I needed to disable a call in readdwarf.c, read_unitinfo_dwarf2, to keep it from crashing. Also, the version number being read in read_debuginfo_dwarf3 is wrong - 512 or 1024, as shown by the DWARF: lines in the log.
Any advice for valgrind dwarf support or compiler build options necessary to fix this would be appreciated.
Update: I used dwarfdump on the hello file and ld-2.12.2.so and it appears to find no problems with the files using the -ka option, so help using that tool and determining what is going on would be great.
Thanks.
Mark Wickham
Digi International
---
$ cat /proc/cpuinfo
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 178.99
Features : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 5
Machine ID : 3419
Hardware : Digi ConnectPort X2
Revision : 28011
Serial : 0000000000000000
$ valgrind -v --leak-check=full --show-reachable=yes ./hello
==844== Memcheck, a memory error detector
==844== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==844== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==844== Command: ./hello
==844==
--844-- Valgrind options:
--844-- -v
--844-- --leak-check=full
--844-- --show-reachable=yes
--844-- Contents of /proc/version:
--844-- Linux version 2.6.35-01661-g850ec9c (markw@markw4) (gcc version 4.4.6 (crosstool-NG 1.12.1) ) #1 PREEMPT Fri Sep 16 17:46:21 CDT 2011
--844-- Arch and hwcaps: ARM, ARMv5
--844-- Page sizes: currently 4096, max supported 4096
--844-- Valgrind library directory: /usr/lib/valgrind
--844-- Reading syms from /hello (0x8000)
Reading UnitInfo at 0x0.....
=> LINES=0x0 NAME=(null) DIR=(null)
debug_line_sz 56, ui.stmt_list 0 (null)
--844-- WARNING: Serious error when reading debug info
--844-- When reading debug info from /hello:
--844-- Only DWARF version 2, 3 and 4 line info is currently supported.
--844-- Reading syms from /lib/ld-2.12.2.so (0x4000000)
Reading UnitInfo at 0x0.....
=> LINES=0x0 NAME=(null) DIR=(null)
debug_line_sz 2593, ui.stmt_list 0 (null)
--844-- WARNING: Serious error when reading debug info
--844-- When reading debug info from /lib/ld-2.12.2.so:
--844-- Last block truncated in .debug_info; ignoring
--844-- Reading suppressions file: /usr/lib/valgrind/default.supp
--844-- REDIR: 0x40172f0 (memcpy) redirected to 0x3803ffe4 (???)
--844-- REDIR: 0x4016860 (strlen) redirected to 0x3803ffb8 (???)
--844-- Reading syms from /usr/lib/valgrind/vgpreload_core-arm-linux.so (0x4826000)
DWARF: 512
--844-- WARNING: Serious error when reading debug info
--844-- When reading debug info from /usr/lib/valgrind/vgpreload_core-arm-linux.so:
--844-- Ignoring non-Dwarf2/3/4 block in .debug_info
--844-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so (0x4830000)
DWARF: 512
--844-- WARNING: Serious error when reading debug info
--844-- When reading debug info from /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so:
--844-- Ignoring non-Dwarf2/3/4 block in .debug_info
DWARF: 1024
--844-- WARNING: Serious error when reading debug info
--844-- When reading debug info from /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so:
--844-- Ignoring non-Dwarf2/3/4 block in .debug_info
--844-- WARNING: Serious error when reading debug info
--844-- When reading debug info from /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so:
--844-- Last block truncated in .debug_info; ignoring
--844-- Reading syms from /lib/libc-2.12.2.so (0x4841000)
DWARF: 512
--844-- WARNING: Serious error when reading debug info
--844-- When reading debug info from /lib/libc-2.12.2.so:
--844-- Ignoring non-Dwarf2/3/4 block in .debug_info
--844-- WARNING: Serious error when reading debug info
--844-- When reading debug info from /lib/libc-2.12.2.so:
--844-- Last block truncated in .debug_info; ignoring
--844-- REDIR: 0x48b4cb8 (rindex) redirected to 0x4834414 (rindex)
--844-- REDIR: 0x48b0bc8 (malloc) redirected to 0x48333e4 (malloc)
--844-- REDIR: 0x48b48c0 (strlen) redirected to 0x4834ae0 (strlen)
Hello!
--844-- REDIR: 0x48b0a4c (free) redirected to 0x4832ecc (free)
--844-- REDIR: 0x48b6260 (memset) redirected to 0x4836594 (memset)
==844==
==844== HEAP SUMMARY:
==844== in use at exit: 8,192 bytes in 1 blocks
==844== total heap usage: 1 allocs, 0 frees, 8,192 bytes allocated
==844==
==844== Searching for pointers to 1 not-freed blocks
==844== Checked 45,680 bytes
==844==
==844== 8,192 bytes in 1 blocks are still reachable in loss record 1 of 1
==844== at 0x4833480: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==844== by 0x8433: main (in /hello)
==844==
==844== LEAK SUMMARY:
==844== definitely lost: 0 bytes in 0 blocks
==844== indirectly lost: 0 bytes in 0 blocks
==844== possibly lost: 0 bytes in 0 blocks
==844== still reachable: 8,192 bytes in 1 blocks
==844== suppressed: 0 bytes in 0 blocks
==844==
==844== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 5)
--844--
--844-- used_suppression: 11 U1004-ARM-_dl_relocate_object
==844==
==844== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 5)
|
|
From: Julian S. <js...@ac...> - 2011-09-21 16:46:27
|
> $ arm-linux-gcc -W -Wall -gdwarf-2 hello.c -o hello What happens if you use plain -g rather than -gdwarf-2 ? J |
|
From: Wickham, M. <Mar...@di...> - 2011-09-21 21:06:03
|
Ok, I have determined the problem. -g also produces DWARF2 symbols with my compiler. The problem is that the symbols are packed, and therefore some of the items are misaligned and on ARM, that typically causes a fault, but on this processor it is reading incorrect values from misaligned addresses. For example, a 32-bit read at an odd address results in a totally bogus value. I think replacing all of the *(UShort *) and *(UInt *) and *(ULong *) expressions in coregrind/m_debuginfo/readdwarf.c with read_UShort() and friends would solve the problem. I was able to verify that it works better if I use this function for the version number reading - now I get DWARF version 2, instead of 512 or 1024. Mark Wickham Digi International --- |
|
From: Tom H. <to...@co...> - 2011-09-21 23:13:48
|
On 21/09/11 22:05, Wickham, Mark wrote: > The problem is that the symbols are packed, and therefore some of the items are misaligned and on ARM, that typically causes a fault, but on this processor it is reading incorrect values from misaligned addresses. For example, a 32-bit read at an odd address results in a totally bogus value. Oh sure, doing unaligned reads on an ARM that isn't in strict alignment mode will get what appear to be undefined values. They are actually well defined, they're just not what you would expect unless you'd been reading the processor manual... > I think replacing all of the *(UShort *) and *(UInt *) and *(ULong *) expressions in coregrind/m_debuginfo/readdwarf.c with read_UShort() and friends would solve the problem. I was able to verify that it works better if I use this function for the version number reading - now I get DWARF version 2, instead of 512 or 1024. Sounds like it, yes. Can you open a bug with this information on it please. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Wickham, M. <Mar...@di...> - 2011-09-22 05:02:45
|
I have submitted bug # 282527. Thanks. Mark Wickham Digi International --- |
|
From: John R. <jr...@bi...> - 2011-09-30 03:15:40
|
On 09/21/2011 04:13 PM, Tom Hughes wrote: > On 21/09/11 22:05, Wickham, Mark wrote: >> I think replacing all of the *(UShort *) and *(UInt *) and *(ULong *) expressions in coregrind/m_debuginfo/readdwarf.c with read_UShort() and friends would solve the problem. I was able to verify that it works better if I use this function for the version number reading - now I get DWARF version 2, instead of 512 or 1024. > > Sounds like it, yes. > > Can you open a bug with this information on it please. Mark entered the bug: https://bugs.kde.org/show_bug.cgi?id=282527 and I have added an attachment of a patch which works moderately well for me on ARM. Who else is working on this? -- |
|
From: John R. <jr...@bi...> - 2011-10-05 03:24:20
|
Please re-open bug 282527. The memcheck option --read-var-info=yes triggers further un-aligned accesses which give bad answers on ARM. [Yes, I'm running the regression tests.] I attached another patch to: https://bugs.kde.org/show_bug.cgi?id=282527 -- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X