[gentoo-amd64] Re: Enabling debug info in Wine?

[Duncan]

"Mark Knecht" <markknecht@×××××.com> posted
5bdc1c8b0803071105v2c295a53we799b81f48fc0b9b@××××××××××.com, excerpted
below, on  Fri, 07 Mar 2008 11:05:42 -0800:

>>  Thanks Duncan. Can you suggest what I minimally need to change to get
>>  good backtrace data out of Wine. I've added ccache, run the command
>>  ccache -M 2G and rebuilt Wine at this point. Just figured I could do
>>  that in the background while I Waited for someone more experience like
>>  you to come along and tell me the right way to do it.

> Sorry. Also added
>
> FEATURES="parallel-fetch distclean ccache confcache splitdebug"
>
> to make.conf

I didn't answer this one because I don't know a lot about wine.  I don't 
use it myself as I don't use closed source and that's sort of the point 
with wine.  Thus, I figured someone else who really knew what they were 
talking about with wine would answer.

Never-the-less, in general, you can add -g to your CFLAGS (CXXFLAGS if 
wine is C++ based, I don't know).  Note that the standard -O2 takes 
optimization shortcuts that confuse debuggers to some extent, so you 
/may/ wish to use plain -O (which is the same as -O1), unless of course 
you are trying to debug something that happens at -O2 but not at -O.  -g, 
as with -O, defaults to a level, in this case -g2.  If you want even more 
debugging output, try -g3, but I'd suggest sticking with -g unless you or 
the wine devs are tracking something special that needs the additional 
data.  There are "a slew" of additional debug switches you can add (see 
the gcc manpage debugging options section for details), but most of them 
are really for debugging what gcc is doing more than for debugging a 
program compiled with gcc.

There's a big caveat here, however.  AFAIK wine is 32-bit only. (??)  If 
so, that means it and/or some of its libraries are likely to be binary-
only 32-bit compatibility packages, if you are using a standard multilib 
profile.  All these compiling options obviously aren't going to do a lot 
of good on binary-only stuff.  You can of course go the 32-bit chroot 
route and thereby compile everything from source, but that's going to be 
an awful lot of work just to debug something if you aren't extremely 
motivated.  OTOH, it DOES give you the opportunity to build the entire 32-
bit side with -g if you want, without interfering with your 64-bit main 
system.  This would be a blocker for many, but I'm not /sure/ wine is 32-
bit only.

If you DO go 32-bit compiling, there's an additional factor with 32-bit 
CFLAGS.  Namely, while -fomit-frame-pointer is a very common bit of 
optimization that doesn't interfere with 64-bit debugging, it DOES 
interfere with 32-bit debugging.  You'll specifically NOT want to include 
it for 32-bit debugging builds.  (With gcc-4.1 and later at least, -O 
automatically turns it on if it does NOT interfere with debugging, thus 
on amd64 64-bit, but NOT on 32-bit x86.  Thus, you don't have to worry 
about -O interference in that regard, just the specific -fomit-frame-
pointer.  However, -fomit-frame-pointer is a very common flag so it's 
worth the entire paragraph of coverage.)

The FEATURES=splitdebug thing helps by splitting the debug info from the 
application itself.  This way the system doesn't have to load the debug 
info unless you are actually debugging.

Note that you may wish or need additional packages merged with debug info 
as well.  These will include the shared object (*.so*) libraries loaded 
by the wine binary.  You can get an idea of which libraries are used with 
ldd.  "ldd /path/to/wine" or to have it grab the path automatically, "ldd 
$(which wine)" .  That'll give you a list of the libs.  You can then use 
"equery b <library>" (b=belongs) to find the package the library file 
belongs to.  Chances are you'll not need to trace into all such libraries 
-- in particular you can probably ignore glibc libs and just assume they 
are "correct", but the closer related something is to the application and 
functionality being debugged, the more likely having it built with 
debugging info will help.

As for a runtime debugger to make use of all the info -g produces, gdb is 
the usual tool there.  Thus, you probably want it merged.  Using it... I 
honestly don't know what I'm doing, but I can follow instructions if a 
developer tells me what they want. =8^)  I'd assume there's a way to tell 
gdb where the split-debug info is, but I don't know it...

That's about it for the general stuff I can help with.  If as I believe, 
wine is 32-bit, it's possible there's not a lot you can do with it unless 
you choose to do the 32-bit chroot thing.  It's possibly still worth 
running gdb on, however, depending on what you are debugging.

At a different level, there's strace.  You can strace any app, 32-bit, 64-
bit, closed source, open source, doesn't matter, because strace doesn't 
actually go into the app to debug, but rather, inserts itself at the 
system-call interface, tracing any kernel calls the program makes.  Thus, 
it's useful for debugging file access type problems or simply finding out 
where a program is looking for things.  As is common with this type of 
program, the volume of output will initially be extremely high. (You'd be 
surprised how many places the system looks for a library, for instance, 
and how many libraries are loaded -- that can easily be thousands of 
lines of output right there, the same for fonts and icons, etc, so if 
that's not what you are looking at, it's easily ten-thousand lines of 
"noise" right there!)  However, there are ways to exclude whole 
categories of output, and one can then use grep -v to exclude even more 
(like all references to /icons and /fonts).  When I run it, I'll normally 
run it several times, deciding each time that there's more "noise" I can 
exclude, until I get it down to something manageable.  Even then, 
redirecting the output to a file and using grep on it can be more 
effective than trying to read the output directly in a terminal window.  
strace isn't really debugging in the traditional debugger sense, but it 
can sure be useful if for instance one's trying to figure out just where 
an app is picking up its config so one can edit it!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@l.g.o mailing list