On Tue, Apr 03, 2012 at 10:47:14AM +0200, Pierre Habouzit wrote: > On Mon, Apr 02, 2012 at 05:37:54PM +0200, Sebastian Rasmussen wrote: > > I have problems running 32-bit binaries in my 64-bit valgrind, however > > this likely a bug related to eglibc or possibly in how valgrind > > depends on eglibc's packages. I expect that both 32-bit and 64-bit > > binaries can be run inside valgrind (or at least that there are > > packages recommended by valgrind that I install to do so). > > The problem is there is not debug symbols packaged as a biarch package > in Debian, meaning that valgrind is mostly useless used with libc6-i386. > In other words there is no libc6-i386-dbg package as you note later: > > > For 64-bit binaries (shown above) /lib/x86_64-linux-gnu/ld-2.13.so > > (installed by libc6) does have a .gnu_debuglink section pointing to > > the debug-version of located in /usr/lib/debug (more specifically > > /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.13.so) which is installed by > > libc6-dbg. > > > To behave properly, you have two roads, either ask the libc maintainer > to provide a libc6-i386-dbg package, which between us, wouldn't really > be the proper way, or more simply, use multiarch. > > For that: > > # dpkg --add-architecture i386 > # apt-get update > # apt-get install libc6-i686:i386 libc6-dbg:i386 > > For *some* reason I don't really understand, the first time I ran your > testing-32 I had to specify the full path to the ld.so in this fashion: > > $ valgrind /lib/i386-linux-gnu/ld-2.13.so ./testing-32 > > But it's now fine and runs properly when I just do: > $ valgrind ./testing-32 > > I've no real clue on *why* it didn't work the first time, probably some > kind of ld.so.cache or something. > > I've put the glibc maintainer in the loop because it's not clear to me > why "valgrind ./testing-32" failed in the first instance, maybe he'll > have a clue, I suspect that "ldconfig" didn't do the right thing because > of the fact that I have three libc's: libc6:amd64, libc6-i686:i386 and > libc6-i386:amd64… and it probably picked the wrong ones.
If that helps: ld.so.conf:include /etc/ld.so.conf.d/*.conf ld.so.conf.d/i486-linux-gnu.conf:# Multiarch support ld.so.conf.d/i486-linux-gnu.conf:/lib/i386-linux-gnu ld.so.conf.d/i486-linux-gnu.conf:/usr/lib/i386-linux-gnu ld.so.conf.d/i486-linux-gnu.conf:/lib/i486-linux-gnu ld.so.conf.d/i486-linux-gnu.conf:/usr/lib/i486-linux-gnu ld.so.conf.d/libc.conf:# libc default configuration ld.so.conf.d/libc.conf:/usr/local/lib ld.so.conf.d/x86_64-linux-gnu.conf:# Multiarch support ld.so.conf.d/x86_64-linux-gnu.conf:/lib/x86_64-linux-gnu ld.so.conf.d/x86_64-linux-gnu.conf:/usr/lib/x86_64-linux-gnu ld.so.conf.d/zz_i386-biarch-compat.conf:# Legacy biarch compatibility support ld.so.conf.d/zz_i386-biarch-compat.conf:/lib32 ld.so.conf.d/zz_i386-biarch-compat.conf:/usr/lib32 Though I'm totally unable to reproduce it so maybe we can waive it as a spurious bug. -- ·O· Pierre Habouzit ··O madco...@debian.org OOO http://www.madism.org -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120403085454.gb5...@madism.org