Debugging 32-bit applications on an x86_64 system

[Jonathan Ryshpan]

Thanks very much for your reply.  Detailed comments follow.

On Sat, 2010-06-19 at 12:48 +0530, Siddhesh Poyarekar wrote:
> On Sat, Jun 19, 2010 at 1:01 AM, Jonathan Ryshpan <jonrysh at pacbell.net> wrote:
> > I'm trying to debug inspect googleearth (a 32-bit application) using gdb
> > on an x86_64 system.  Gdb starts OK, but when I attempt to run
> > googleearth, it reports that a large number of debuginfo packages are
> > missing with messages like:
> >        Missing separate debuginfo for /lib/libexpat.so.1
> >        Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/f4/6a67411322c129b167dd758b8ab9cbd2e4ddf9.debug
> > When I attempt to run yum to carry this out, yum produces error messages
> > like:
> >        file /usr/lib/debug/usr/bin/xmlwf.debug from install of expat-debuginfo-2.0.1-10.fc13.i686 conflicts with file from package expat-debuginfo-2.0.1-10.fc13.x86_64
> > Apparently, the debug info for the *library* /lib/libexpat.so.1 is
> > packaged in the same rpm with the debug info for the *executable* xmlwf.
> > And since executables on x86_64 system are not segregated by execution
> > model (32-bit vs. 64-bit) there is a file name conflict.
> >
> > (A question) Is there any way to load the debug info for these 32-bit
> > library without removing the debug info for 64-bit libraries?  This
> > would be tedious, since there are about 100 64-bit debug packages on the
> > system currently.
> 
> You could download the debuginfo rpm, decompress it using rpm2cpio and
> the load up the program with LD_LIBRARY_PATH pointing to the location
> where you decompressed it.

Again, this would be tedious, since there are 33 debuginfo packages that
need to be loaded.

> And you also ought to be reporting this as a bug, since ideally the
> package should be split up to separate xmlwf from expat. Maybe
> discussion on the fedora devel list would make this clearer:

This is not a particular bug, but rather a *kind* of bug.  I don't think
all 33 packages have this problem, but enough of them do to create a lot
of trouble.  In fact none of the 33 debuginfo packages would load.

> https://admin.fedoraproject.org/mailman/listinfo/devel

I assume you are pointing to the list in general, and not to any special
discussion.

> > (A suggestion) On x86_64 systems 32-bit executables and 64-bit
> > executables should be in separate directories: say /usr/bin32
> > and /usr/bin/64.  An addition directory /usr/bin would contain
> > (symbolic) links to default executables.  (I think this would keep all
> > current shell scripts, etc., running.)  Maybe the same file structure
> > -- /usr/lib32 /usr/lib64 and /usr/lib -- would also be good for
> > libraries.
> >
> 
> No, because the way forward is to eliminate the need for 32 bit
> binaries on 64 bit systems. The libraries are there now because we
> still have a lot of programs that are built as 32 bit only (flash).

Indeed the *best* way forward is to eliminate proprietary packages, or
(at least) to have proprietary code released in source form for Linux
only, as (I think) qt and ghostscript are.  Then getting 64-bit packages
requires not too much more than recompilation.

But lets not hold our breath.  The open source driver (nouveau) for my
video card (Nvidia GeForce 9500 GT) does not utilize the full capacity
of the card; the proprietary driver (kmod-nvidia) is broken, and causes
Google Earth (yet another proprietary program, which I'm very fond of)
to crash on startup.  The open source Flash plugin for Firefox has been
under development for years, and still doesn't display many (most?)
Flash URLs.  The proprietary Flash plugin (64-bit) makes Firefox crash
on termination.

The suggestion gives maybe the best way forward under the circumstances.

Thanks again - jon