From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JXnet-0004ru-W4 for garchives@archives.gentoo.org; Sat, 08 Mar 2008 01:15:32 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 204AAE0557; Sat, 8 Mar 2008 01:15:30 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by pigeon.gentoo.org (Postfix) with ESMTP id 91258E0557 for ; Sat, 8 Mar 2008 01:15:29 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JXnek-0005J7-JJ for gentoo-amd64@lists.gentoo.org; Sat, 08 Mar 2008 01:15:22 +0000 Received: from ip68-231-12-179.ph.ph.cox.net ([68.231.12.179]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 08 Mar 2008 01:15:22 +0000 Received: from 1i5t5.duncan by ip68-231-12-179.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 08 Mar 2008 01:15:22 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Enabling debug info in Wine? Date: Sat, 8 Mar 2008 01:15:10 +0000 (UTC) Message-ID: References: <5bdc1c8b0803070809x78898edegd3e2fa8f515582e8@mail.gmail.com> <5bdc1c8b0803070847y3094bde9j7aa9a6a64500a033@mail.gmail.com> <47D17469.70703@xaerolimit.net> <5bdc1c8b0803070921xbc44366we4b3d6b3d9615bfd@mail.gmail.com> <5bdc1c8b0803071103w4941f26bwafee1942709f2c78@mail.gmail.com> <5bdc1c8b0803071105v2c295a53we799b81f48fc0b9b@mail.gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-12-179.ph.ph.cox.net User-Agent: Pan/0.132 (Waxed in Black) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 9b9820a7-3fc0-448e-a696-72523d82958e X-Archives-Hash: 2c6d81f4f58ed1c94741e72dfb1df071 "Mark Knecht" posted 5bdc1c8b0803071105v2c295a53we799b81f48fc0b9b@mail.gmail.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 lik= e >> you to come along and tell me the right way to do it. > Sorry. Also added >=20 > FEATURES=3D"parallel-fetch distclean ccache confcache splitdebug" >=20 > to make.conf I didn't answer this one because I don't know a lot about wine. I don't=20 use it myself as I don't use closed source and that's sort of the point=20 with wine. Thus, I figured someone else who really knew what they were=20 talking about with wine would answer. Never-the-less, in general, you can add -g to your CFLAGS (CXXFLAGS if=20 wine is C++ based, I don't know). Note that the standard -O2 takes=20 optimization shortcuts that confuse debuggers to some extent, so you=20 /may/ wish to use plain -O (which is the same as -O1), unless of course=20 you are trying to debug something that happens at -O2 but not at -O. -g,= =20 as with -O, defaults to a level, in this case -g2. If you want even more= =20 debugging output, try -g3, but I'd suggest sticking with -g unless you or= =20 the wine devs are tracking something special that needs the additional=20 data. There are "a slew" of additional debug switches you can add (see=20 the gcc manpage debugging options section for details), but most of them=20 are really for debugging what gcc is doing more than for debugging a=20 program compiled with gcc. There's a big caveat here, however. AFAIK wine is 32-bit only. (??) If=20 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=20 profile. All these compiling options obviously aren't going to do a lot=20 of good on binary-only stuff. You can of course go the 32-bit chroot=20 route and thereby compile everything from source, but that's going to be=20 an awful lot of work just to debug something if you aren't extremely=20 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=20 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=20 CFLAGS. Namely, while -fomit-frame-pointer is a very common bit of=20 optimization that doesn't interfere with 64-bit debugging, it DOES=20 interfere with 32-bit debugging. You'll specifically NOT want to include= =20 it for 32-bit debugging builds. (With gcc-4.1 and later at least, -O=20 automatically turns it on if it does NOT interfere with debugging, thus=20 on amd64 64-bit, but NOT on 32-bit x86. Thus, you don't have to worry=20 about -O interference in that regard, just the specific -fomit-frame- pointer. However, -fomit-frame-pointer is a very common flag so it's=20 worth the entire paragraph of coverage.) The FEATURES=3Dsplitdebug thing helps by splitting the debug info from th= e=20 application itself. This way the system doesn't have to load the debug=20 info unless you are actually debugging. Note that you may wish or need additional packages merged with debug info= =20 as well. These will include the shared object (*.so*) libraries loaded=20 by the wine binary. You can get an idea of which libraries are used with= =20 ldd. "ldd /path/to/wine" or to have it grab the path automatically, "ldd= =20 $(which wine)" . That'll give you a list of the libs. You can then use=20 "equery b " (b=3Dbelongs) to find the package the library file=20 belongs to. Chances are you'll not need to trace into all such libraries= =20 -- in particular you can probably ignore glibc libs and just assume they=20 are "correct", but the closer related something is to the application and= =20 functionality being debugged, the more likely having it built with=20 debugging info will help. As for a runtime debugger to make use of all the info -g produces, gdb is= =20 the usual tool there. Thus, you probably want it merged. Using it... I=20 honestly don't know what I'm doing, but I can follow instructions if a=20 developer tells me what they want. =3D8^) I'd assume there's a way to te= ll=20 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,=20 wine is 32-bit, it's possible there's not a lot you can do with it unless= =20 you choose to do the 32-bit chroot thing. It's possibly still worth=20 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=20 actually go into the app to debug, but rather, inserts itself at the=20 system-call interface, tracing any kernel calls the program makes. Thus,= =20 it's useful for debugging file access type problems or simply finding out= =20 where a program is looking for things. As is common with this type of=20 program, the volume of output will initially be extremely high. (You'd be= =20 surprised how many places the system looks for a library, for instance,=20 and how many libraries are loaded -- that can easily be thousands of=20 lines of output right there, the same for fonts and icons, etc, so if=20 that's not what you are looking at, it's easily ten-thousand lines of=20 "noise" right there!) However, there are ways to exclude whole=20 categories of output, and one can then use grep -v to exclude even more=20 (like all references to /icons and /fonts). When I run it, I'll normally= =20 run it several times, deciding each time that there's more "noise" I can=20 exclude, until I get it down to something manageable. Even then,=20 redirecting the output to a file and using grep on it can be more=20 effective than trying to read the output directly in a terminal window. =20 strace isn't really debugging in the traditional debugger sense, but it=20 can sure be useful if for instance one's trying to figure out just where=20 an app is picking up its config so one can edit it! --=20 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 --=20 gentoo-amd64@lists.gentoo.org mailing list