|
From: Florian K. <fl...@ei...> - 2014-09-05 17:12:57
|
This revision breaks stuff for me (x86-64, ubuntu 14.04, gcc 4.8.2, EGLIBC 2.19-0ubuntu6.3). On a brand-new checkout I get this: ./vg-in-place date valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: strlen valgrind: in an object with soname matching: ld-linux-x86-64.so.2 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux-x86-64.so.2 valgrind: ... and so on Works fine without the revision. Florian |
|
From: Mark W. <mj...@re...> - 2014-09-05 18:15:56
|
On Fri, 2014-09-05 at 19:12 +0200, Florian Krohm wrote: > This revision breaks stuff for me (x86-64, ubuntu 14.04, gcc 4.8.2, > EGLIBC 2.19-0ubuntu6.3). > On a brand-new checkout I get this: > > ./vg-in-place date > valgrind: Fatal error at startup: a function redirection > valgrind: which is mandatory for this platform-tool combination > valgrind: cannot be set up. Details of the redirection are: > valgrind: > valgrind: A must-be-redirected function > valgrind: whose name matches the pattern: strlen > valgrind: in an object with soname matching: ld-linux-x86-64.so.2 > valgrind: was not found whilst processing > valgrind: symbols from the object with soname: ld-linux-x86-64.so.2 > valgrind: > ... and so on > > Works fine without the revision. That is surprising. The patch was supposed to extend the debug files/patchs being searched. Apparently I messed things up and instead of finding the debug for ld-linux-x86-64.so.2 it now doesn't and so cannot setup the redirect. But I though we required ld.so not be stripped from the symbol table. hmmm. Would you mind posting the valgrind -v output before and after the patch so we can see which files are being considered before/after the patch? Thanks, Mark |
|
From: Florian K. <fl...@ei...> - 2014-09-05 18:21:43
|
On 05.09.2014 20:15, Mark Wielaard wrote: > On Fri, 2014-09-05 at 19:12 +0200, Florian Krohm wrote: >> This revision breaks stuff for me (x86-64, ubuntu 14.04, gcc 4.8.2, >> EGLIBC 2.19-0ubuntu6.3). >> On a brand-new checkout I get this: >> >> ./vg-in-place date >> valgrind: Fatal error at startup: a function redirection >> valgrind: which is mandatory for this platform-tool combination >> valgrind: cannot be set up. Details of the redirection are: >> valgrind: >> valgrind: A must-be-redirected function >> valgrind: whose name matches the pattern: strlen >> valgrind: in an object with soname matching: ld-linux-x86-64.so.2 >> valgrind: was not found whilst processing >> valgrind: symbols from the object with soname: ld-linux-x86-64.so.2 >> valgrind: >> ... and so on >> >> Works fine without the revision. > > That is surprising. The patch was supposed to extend the debug > files/patchs being searched. Apparently I messed things up and instead > of finding the debug for ld-linux-x86-64.so.2 it now doesn't and so > cannot setup the redirect. But I though we required ld.so not be > stripped from the symbol table. hmmm. > > Would you mind posting the valgrind -v output before and after the patch > so we can see which files are being considered before/after the patch? > Here they are from: ./vg-in-place -v date |
|
From: Mark W. <mj...@re...> - 2014-09-05 18:27:45
|
On Fri, 2014-09-05 at 20:21 +0200, Florian Krohm wrote: > On 05.09.2014 20:15, Mark Wielaard wrote: > > Would you mind posting the valgrind -v output before and after the patch > > so we can see which files are being considered before/after the patch? > > > > Here they are from: > ./vg-in-place -v date Thanks, I think I see what is going wrong. The search tries the file itself first (maybe debug info is in the file itself). Before it checked the debug CRC, which didn't match, and so it tries a separate debug file. But after it just checks the build-id, which does match and so doesn't consider any more separate debug files. BTW. Do you need to have libc6-dbg installed on Ubuntu before valgrind works? If not could you also post the output before/after without libc6-dbg installed? I'll try to fix it. Sorry for the breakage. Thanks, Mark |
|
From: Mark W. <mj...@re...> - 2014-09-05 22:57:26
|
On Fri, Sep 05, 2014 at 08:27:30PM +0200, Mark Wielaard wrote:
> Thanks, I think I see what is going wrong. The search tries the file
> itself first (maybe debug info is in the file itself). Before it checked
> the debug CRC, which didn't match, and so it tries a separate debug
> file. But after it just checks the build-id, which does match and so
> doesn't consider any more separate debug files.
I contemplated various "smart tricks" for avoiding having to do a full
CRC check. But decided just before the release that was too risky and
I might break something yet again... So the following simple patch
was pushed as r14474 which should fix the issue and make things as
they were (always checking the crc if we have one).
After the release we can try to come up with something more clever.
Also note that if we have a buildid we will always try and search
for a debug file even if the main file already has a full symtab
and debug sections. That is also inefficient. Another thing to clean
up after the release.
Cheers,
Mark
diff --git a/coregrind/m_debuginfo/readelf.c b/coregrind/m_debuginfo/readelf.c
index 86186d3..75fa469 100644
--- a/coregrind/m_debuginfo/readelf.c
+++ b/coregrind/m_debuginfo/readelf.c
@@ -1180,7 +1180,12 @@ DiImage* open_debug_file( const HChar* name, const HChar* buildid, UInt crc,
VG_(message)(Vg_DebugMsg, " Considering %s ..\n", name);
}
- if (buildid) {
+ /* We will always check the crc if we have one (altfiles don't have one)
+ for now because we might be opening the main file again by any other
+ name, and that obviously also has the same buildid. More efficient
+ would be an fstat bases check or a check that the file actually
+ contains .debug* sections. */
+ if (buildid && crc == 0) {
HChar* debug_buildid = find_buildid(dimg, rel_ok, True);
if (debug_buildid == NULL || VG_(strcmp)(buildid, debug_buildid) != 0) {
ML_(img_done)(dimg);
|
|
From: Florian K. <fl...@ei...> - 2014-09-05 18:34:36
|
On 05.09.2014 20:27, Mark Wielaard wrote: > BTW. Do you need to have libc6-dbg installed on Ubuntu before valgrind > works? If not could you also post the output before/after without > libc6-dbg installed? I need to have it installed. When I remove it I get the same message as before. So, yes, it needs to be present. > > I'll try to fix it. Sorry for the breakage. no problem. Florian |
|
From: Mark W. <mj...@re...> - 2014-09-05 23:22:01
|
On Fri, Sep 05, 2014 at 08:34:16PM +0200, Florian Krohm wrote: > On 05.09.2014 20:27, Mark Wielaard wrote: > > > BTW. Do you need to have libc6-dbg installed on Ubuntu before valgrind > > works? If not could you also post the output before/after without > > libc6-dbg installed? > > I need to have it installed. When I remove it I get the same message as > before. So, yes, it needs to be present. That is unfortunate. I double checked on a Debian wheezy setup and my commit does seem to fix it. But I had some trouble with 32-on-64 programs, since I couldn't find the corresponding libc6-dbg-i386 package. What is the correct package to install to make i386 programs work under valgrind on a amd64 setup? Thanks, Mark |
|
From: Florian K. <fl...@ei...> - 2014-09-06 10:30:23
|
On 06.09.2014 01:21, Mark Wielaard wrote: > On Fri, Sep 05, 2014 at 08:34:16PM +0200, Florian Krohm wrote: >> On 05.09.2014 20:27, Mark Wielaard wrote: >> >>> BTW. Do you need to have libc6-dbg installed on Ubuntu before valgrind >>> works? If not could you also post the output before/after without >>> libc6-dbg installed? >> >> I need to have it installed. When I remove it I get the same message as >> before. So, yes, it needs to be present. > > That is unfortunate. I double checked on a Debian wheezy setup and > my commit does seem to fix it. It does fix it. Thanks! > But I had some trouble with 32-on-64 > programs, since I couldn't find the corresponding libc6-dbg-i386 > package. What is the correct package to install to make i386 programs > work under valgrind on a amd64 setup? Dunno. I think Ivo answered it in his reply. Florian |
|
From: Ivo R. <iv...@iv...> - 2014-09-06 04:06:08
|
2014-09-06 1:21 GMT+02:00 Mark Wielaard <mj...@re...>: > > That is unfortunate. I double checked on a Debian wheezy setup and > my commit does seem to fix it. But I had some trouble with 32-on-64 > programs, since I couldn't find the corresponding libc6-dbg-i386 > package. What is the correct package to install to make i386 programs > work under valgrind on a amd64 setup? > Hello Mark, It is libc6-dbg:i386 (the name is a bit arcane). You also need gcc-multilib and libc6-dev-i386 to build the valgrind with 32-bit support. Kind regards, I. |
|
From: Mark W. <mj...@re...> - 2014-09-06 15:07:06
|
On Sat, 2014-09-06 at 06:06 +0200, Ivo Raisr wrote: > 2014-09-06 1:21 GMT+02:00 Mark Wielaard <mj...@re...>: > > That is unfortunate. I double checked on a Debian wheezy setup and > > my commit does seem to fix it. But I had some trouble with 32-on-64 > > programs, since I couldn't find the corresponding libc6-dbg-i386 > > package. What is the correct package to install to make i386 programs > > work under valgrind on a amd64 setup? > > > > It is libc6-dbg:i386 (the name is a bit arcane). > You also need gcc-multilib and libc6-dev-i386 to build the valgrind with > 32-bit support. Thanks, I still couldn't install it until I figured out I also needed to do dpkgdpkg --add-architecture i386 && aptitude update first. There is a debian bug about this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695218 But IMHO debian really shouldn't strip the symbol table from ld.so, that is really inconvenient :{ Cheers, Mark |
|
From: Mark W. <mj...@re...> - 2014-09-06 17:46:45
|
On Sat, 2014-09-06 at 17:06 +0200, Mark Wielaard wrote: > Thanks, I still couldn't install it until I figured out I also needed to > do dpkgdpkg --add-architecture i386 && aptitude update first. > There is a debian bug about this: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695218 And with that installed I now have: C compiler: gcc (Debian 4.7.2-5) 4.7.2 GDB: GNU gdb (GDB) 7.4.1-debian Assembler: GNU assembler (GNU Binutils for Debian) 2.22 C library: GNU C Library (Debian EGLIBC 2.13-38+deb7u4) stable release version 2.13 uname -mrs: Linux 3.2.0-4-amd64 x86_64 Vendor version: Debian GNU/Linux 7 (wheezy) Which provides the following regtest result: == 684 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == So that is looking pretty good. > But IMHO debian really shouldn't strip the symbol table from ld.so, that > is really inconvenient :{ This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721383 Cheers, Mark |