|
From: Igmar P. <mai...@jd...> - 2005-06-22 14:23:11
|
Hi, I've done a build today, and had a few ,minor glitches : - pub/libvex_guest_offsets.h isn't generated, so the compile bails out. - priv/main/vex_svnversion.h isn't generated either - memcheck/tests/x86/scalar.x includes asm/ipc.h, which gives nasty errors in this environment. Changing to sys/ipc.h seems to fix things. 'make check' requires g++, we might want to check for this in configure, since I didn't have it installed :) Hope this helps. Regards, Igmar |
|
From: Tom H. <to...@co...> - 2005-06-22 14:30:45
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
> - pub/libvex_guest_offsets.h isn't generated, so the compile bails out.
It should do as some of the source files depend upon it. There is
a bug where it doesn't get regenerated if the program that generates
it changes but from a clean checkout it should be generated.
> - priv/main/vex_svnversion.h isn't generated either
So you didn't do "make version" then? The instructions on the web
site do tell you to do that ;-)
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Igmar P. <mai...@jd...> - 2005-06-23 08:22:33
|
> > - pub/libvex_guest_offsets.h isn't generated, so the compile bails out. > > It should do as some of the source files depend upon it. There is > a bug where it doesn't get regenerated if the program that generates > it changes but from a clean checkout it should be generated. It works indeed. No idea what made it fail the first time. > > - priv/main/vex_svnversion.h isn't generated either > > So you didn't do "make version" then? The instructions on the web > site do tell you to do that ;-) hehehe.. Hmm.. I totally missed those. My remark about the asm/ipc.h include however still sticks, as inclusing asm/* linux/* usually leads to errors :) make regtest also totall fails : *** threaded-fork failed (stderr) *** tls: valgrind ./tls *** tls failed (stderr) *** -- Running tests in none/tests/x86 ------------------------------------ badseg: valgrind ./badseg *** badseg failed (stderr) *** bt_everything: valgrind ./bt_everything *** bt_everything failed (stderr) *** bt_literal: valgrind ./bt_literal The above is shown with all tests. Regards, Igmar |
|
From: Nicholas N. <nj...@cs...> - 2005-06-30 04:44:53
|
On Thu, 23 Jun 2005, Igmar Palsenberg wrote: > My remark about the asm/ipc.h > include however still sticks, as inclusing asm/* linux/* usually leads to > errors :) I've removed the asm/ipc.h include from scalar.c. > make regtest also totall fails : > > *** threaded-fork failed (stderr) *** > tls: valgrind ./tls > *** tls failed (stderr) *** > -- Running tests in none/tests/x86 ------------------------------------ > badseg: valgrind ./badseg > *** badseg failed (stderr) *** > bt_everything: valgrind ./bt_everything > *** bt_everything failed (stderr) *** > bt_literal: valgrind ./bt_literal > > The above is shown with all tests. What do the *.stderr.exp files look like? Are they all failing in the same way? Thanks. N |
|
From: Igmar P. <mai...@jd...> - 2005-07-01 07:23:36
|
> > *** bt_everything failed (stderr) *** > > bt_literal: valgrind ./bt_literal > > > > The above is shown with all tests. > > What do the *.stderr.exp files look like? Are they all failing in the > same way? This is a 'fix one and you fix them all' issue AFAIK : closeall.stderr.out : DWARF2 CFI reader: unhandled CFI instruction 0:50 DWARF2 CFI reader: unhandled CFI instruction 0:50 Those line always show in pairs of 2. Valgrind does also show when actually using it, but it seems to operate correctly at a first glance. System info (this is a standard Debian stable system with a 2.6.10 kernel). igmar@ouzo:~/valgrind_3/valgrind/none/tests$ gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-13) igmar@ouzo:~/valgrind_3/valgrind/none/tests$ ld -v GNU ld version 2.15 igmar@ouzo:~/valgrind_3/valgrind/none/tests$ /lib/libc.so.6 GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.3.5 (Debian 1:3.3.5-12). Compiled on a Linux 2.6.0-test7 system on 2005-05-10. Regards, Igmar |
|
From: Julian S. <js...@ac...> - 2005-07-01 08:45:53
|
> DWARF2 CFI reader: unhandled CFI instruction 0:50
> DWARF2 CFI reader: unhandled CFI instruction 0:50
This would be easy enough to fix if only I had a clue what CFI
instruction #50 (0x32) is. Neither the DWARF3 spec nor the gdb-6.3
sources ("the ultimate reference" :-) mention it. I suspect
it's some GNUish extension.
Could you email me the executable itself (closeall, I mean) and
I'll prod it with readelf and see what happens.
J
|
|
From: Igmar P. <mai...@jd...> - 2005-07-01 09:03:40
|
> > DWARF2 CFI reader: unhandled CFI instruction 0:50
> > DWARF2 CFI reader: unhandled CFI instruction 0:50
>
> This would be easy enough to fix if only I had a clue what CFI
> instruction #50 (0x32) is.
No idea. I can't find it anywhere. I've put a load of fprintf() statements
in gdb 6.3's dwarf parser, and CFI #50 simply doesn't show up.
In gdb 6.3's gdb/dwarf2-frame.c::execeute_cfa_program() :
while (insn_ptr < insn_end && fs->pc <= pc)
{
unsigned char insn = *insn_ptr++;
ULONGEST utmp, reg;
LONGEST offset;
//fprintf(stderr, "insn %d (%.2x)\n", insn, insn);
if (insn == 0x32) {
fprintf(stderr, "INSN == 50 encountered !!!\n");
}
if ((insn & 0x3f) == 0x32) {
fprintf(stderr, "INSN &0x3f == 50 encountered !!!\n");
}
and it returns nothing. It does work : If I add one for opcode 0 (NOOP),
it prints when doing a step.
> Neither the DWARF3 spec nor the gdb-6.3
> sources ("the ultimate reference" :-) mention it. I suspect
> it's some GNUish extension.
I suspect it's something that is feeding the DWARF parser, not the parser
itself.
> Could you email me the executable itself (closeall, I mean) and
> I'll prod it with readelf and see what happens.
All exec's do, so I'll mail you the exec of a main() simply returning.
Regards,
Igmar
|
|
From: Rob L. <ro...@te...> - 2006-01-06 21:59:31
|
On Fri, Jul 01, 2005 at 09:45:39AM +0100, Julian Seward wrote:
>
> > DWARF2 CFI reader: unhandled CFI instruction 0:50
> > DWARF2 CFI reader: unhandled CFI instruction 0:50
>
> This would be easy enough to fix if only I had a clue what CFI
> instruction #50 (0x32) is. Neither the DWARF3 spec nor the gdb-6.3
> sources ("the ultimate reference" :-) mention it. I suspect
> it's some GNUish extension.
>
> Could you email me the executable itself (closeall, I mean) and
> I'll prod it with readelf and see what happens.
I'm seeing this message with valgrind 3.1.0. I've got a small
executable that gives this message and the source code (for what it's
worth).
http://terizla.org/~robl/tmp/try
http://terizla.org/~robl/tmp/try.c
==rob
--
Rob Latham Chicago, IL USA
|
|
From: Robert W. <rj...@du...> - 2005-07-01 21:05:06
|
> > DWARF2 CFI reader: unhandled CFI instruction 0:50
> > DWARF2 CFI reader: unhandled CFI instruction 0:50
>
> This would be easy enough to fix if only I had a clue what CFI
> instruction #50 (0x32) is. Neither the DWARF3 spec nor the gdb-6.3
> sources ("the ultimate reference" :-) mention it. I suspect
> it's some GNUish extension.
>
> Could you email me the executable itself (closeall, I mean) and
> I'll prod it with readelf and see what happens.
What is the CFI reader anyway? I can't find a reference to the term
"cfi" anywhere in libdwarf. Is it supposed to be a CFA, perhaps?
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-01 21:11:18
|
On Fri, 1 Jul 2005, Robert Walsh wrote: > What is the CFI reader anyway? I can't find a reference to the term > "cfi" anywhere in libdwarf. Is it supposed to be a CFA, perhaps? It's short for "Call Frame Instructions". I believe the info helps with stack tracing -- Julian had to implement CFI reading support to get good stack traces on AMD64. N |
|
From: Julian S. <js...@ac...> - 2006-01-06 22:07:33
|
On Friday 06 January 2006 21:59, Rob Latham wrote:
> On Fri, Jul 01, 2005 at 09:45:39AM +0100, Julian Seward wrote:
> > > DWARF2 CFI reader: unhandled CFI instruction 0:50
> > > DWARF2 CFI reader: unhandled CFI instruction 0:50
> >
> > This would be easy enough to fix if only I had a clue what CFI
> > instruction #50 (0x32) is. Neither the DWARF3 spec nor the gdb-6.3
> > sources ("the ultimate reference" :-) mention it. I suspect
> > it's some GNUish extension.
> >
> > Could you email me the executable itself (closeall, I mean) and
> > I'll prod it with readelf and see what happens.
>
> I'm seeing this message with valgrind 3.1.0.
Last I heard (if I remember correctly) this was caused by a bug in
the CFI info attached to glibc.so or ld.so in SuSE 9.3. Is this
on SuSE 9.3 on a low-end x86?
J
|
|
From: Igmar P. <mai...@jd...> - 2006-01-09 07:43:06
|
> Last I heard (if I remember correctly) this was caused by a bug in > the CFI info attached to glibc.so or ld.so in SuSE 9.3. Is this > on SuSE 9.3 on a low-end x86? Debian Stable (3.1) also has this. Since I'll probably switch to CentOS soon, it will probably go away :) Regards, Igmar |
|
From: Rob L. <ro...@te...> - 2006-01-06 22:18:25
|
On Fri, Jan 06, 2006 at 10:07:25PM +0000, Julian Seward wrote: > > I'm seeing this message with valgrind 3.1.0. > > Last I heard (if I remember correctly) this was caused by a bug in > the CFI info attached to glibc.so or ld.so in SuSE 9.3. Is this > on SuSE 9.3 on a low-end x86? I'm seeing this on debian's libc6-2.3.2.ds1-22 on an elderly (3+ years) but not really low-end x86. Seems like a harmless error. Just wasn't sure if you wanted more information about it or not. ==rob -- Rob Latham Chicago, IL USA |
|
From: Tom S. <to...@pl...> - 2006-01-07 00:45:01
|
Rob Latham wrote: > On Fri, Jan 06, 2006 at 10:07:25PM +0000, Julian Seward wrote: > >>>I'm seeing this message with valgrind 3.1.0. >> >>Last I heard (if I remember correctly) this was caused by a bug in >>the CFI info attached to glibc.so or ld.so in SuSE 9.3. Is this >>on SuSE 9.3 on a low-end x86? > > > I'm seeing this on debian's libc6-2.3.2.ds1-22 on an elderly (3+ > years) but not really low-end x86. > > Seems like a harmless error. Just wasn't sure if you wanted more > information about it or not. > > ==rob > valgrind 3.1.0 just hit Debian testing a few days ago, and I am now seeing this as well. I was planning on trying on running the tarball version of valgrind rather than the Debian packaged version to see if it made a difference, but I haven't gotten to that yet. $ dpkg -l valgrind libc6 gcc-3.3 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii gcc-3.3 3.3.6-10 The GNU C compiler ii libc6 2.3.5-8 GNU C Library: Shared libraries and ii valgrind 3.1.0-2 A memory debugger and profiler -- Tom Schutter (mailto:to...@pl...) Platte River Associates, Inc. (http://www.platte.com) |
|
From: Julian S. <js...@ac...> - 2006-01-07 12:45:01
|
On Friday 06 January 2006 23:18, Tom Schutter wrote:
> Rob Latham wrote:
> > On Fri, Jan 06, 2006 at 10:07:25PM +0000, Julian Seward wrote:
> >>>I'm seeing this message with valgrind 3.1.0.
> >>
> >>Last I heard (if I remember correctly) this was caused by a bug in
> >>the CFI info attached to glibc.so or ld.so in SuSE 9.3. Is this
> >>on SuSE 9.3 on a low-end x86?
> >
> > I'm seeing this on debian's libc6-2.3.2.ds1-22 on an elderly (3+
> > years) but not really low-end x86.
> >
> > Seems like a harmless error. Just wasn't sure if you wanted more
> > information about it or not.
> >
> > =3D=3Drob
>
> valgrind 3.1.0 just hit Debian testing a few days ago, and I am now
> seeing this as well. I was planning on trying on running the tarball
> version of valgrind rather than the Debian packaged version to see
> if it made a difference, but I haven't gotten to that yet.
Here's an excerpt from SuSE-9.3 related email:
--11932-- DWARF2 CFI reader: unhandled CFI instruction 0:50
These appear in both /lib/tls/libc.so.6 and /lib/tls/libpthread.so.0.
I could not find what these were by looking in the DWARF3 spec.
=20
So I asked readelf to read the call-frame-info and it has no idea
either:
=20
sewardj@nemesis:~/VgHACKED/trunk$ readelf
--debug-dump=3Dframes /lib/tls/libc.so.6 > /dev/null
readelf: Warning: unsupported or unknown DW_CFA_50
readelf: Warning: unsupported or unknown DW_CFA_50
=46rom this I was convinced that the CFA info from the libraries itself
was bad, since readelf was also complaining about it. What do you get
if you try the same on Debian testing?
In any case it's a pretty harmless problem except for the fact that it
causes V to fail all its regression tests. One easy fix/kludge you
might want to consider is to comment out the line that prints that=20
message. I think it's in coregrind/m_debuginfo/dwarf.c.
J
|
|
From: Tom S. <to...@pl...> - 2006-01-09 16:57:50
|
Julian Seward wrote: > Here's an excerpt from SuSE-9.3 related email: > > --11932-- DWARF2 CFI reader: unhandled CFI instruction 0:50 > These appear in both /lib/tls/libc.so.6 and /lib/tls/libpthread.so.0. > I could not find what these were by looking in the DWARF3 spec. > > So I asked readelf to read the call-frame-info and it has no idea > either: > > sewardj@nemesis:~/VgHACKED/trunk$ readelf > --debug-dump=frames /lib/tls/libc.so.6 > /dev/null > readelf: Warning: unsupported or unknown DW_CFA_50 > readelf: Warning: unsupported or unknown DW_CFA_50 > > From this I was convinced that the CFA info from the libraries itself > was bad, since readelf was also complaining about it. What do you get > if you try the same on Debian testing? I get identical results with Debian testing: rota:~$ readelf --debug-dump=frames /lib/tls/libc.so.6 > /dev/null readelf: Warning: unsupported or unknown DW_CFA_50 readelf: Warning: unsupported or unknown DW_CFA_50 For the archives, the version of libc.so.6 is 2.3.5-8. -- Tom Schutter (mailto:to...@pl...) Platte River Associates, Inc. (http://www.platte.com) |