[gentoo-amd64] Enabling debug info in Wine?

[gentoo-amd64] Enabling debug info in Wine?

[Mark Knecht]

Hi all,
   What would be a sufficient set of actions for me to take to get
backtrace info from Wine that would be useful to Wine devlopers? Their
Bugzilla folks are are saying, correctly I think, that everything
necessary is stripped out and that the info I'm providing doesn't
help. I don't see anything specific in the Wine flags.

   Is this some sort of major effort required where I have to go back
and recompile many things on my system or is there a way to compile
just Wine to give them what they need?

   I found this page to read:

http://www.gentoo.org/proj/en/qa/backtraces.xml

   I do not understand the nostrip/splitdebug topic. I do not find
either word in man emerge or man portage. Is this a gcc thing?

   My current gcc flags look like this:

CFLAGS="-march=k8 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j2"

   Any comments about whether those are good or not for a
non-developer, desktop user type like me would be appreciated. I don't
mind changing cflags to get these folks what they want.

Thanks,
Mark
-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Mark Knecht]

On Fri, Mar 7, 2008 at 8:09 AM, Mark Knecht <markknecht@gmail.com> wrote:
> Hi all,
>    What would be a sufficient set of actions for me to take to get
>  backtrace info from Wine that would be useful to Wine devlopers? Their
>  Bugzilla folks are are saying, correctly I think, that everything
>  necessary is stripped out and that the info I'm providing doesn't
>  help. I don't see anything specific in the Wine flags.
>
>    Is this some sort of major effort required where I have to go back
>  and recompile many things on my system or is there a way to compile
>  just Wine to give them what they need?
>
>    I found this page to read:
>
>  http://www.gentoo.org/proj/en/qa/backtraces.xml
>
>    I do not understand the nostrip/splitdebug topic. I do not find
>  either word in man emerge or man portage. Is this a gcc thing?
>
>    My current gcc flags look like this:
>
>  CFLAGS="-march=k8 -O2 -pipe"
>  CHOST="x86_64-pc-linux-gnu"
>  CXXFLAGS="${CFLAGS}"
>  MAKEOPTS="-j2"
>
>    Any comments about whether those are good or not for a
>  non-developer, desktop user type like me would be appreciated. I don't
>  mind changing cflags to get these folks what they want.
>
>  Thanks,
>  Mark
>

OK, so this seems to be part of using the FEATURES=" ... " line in make.conf.

I do not have a FEATURES line at all so I'm hesitant to just start
throwing things in. <<glug...help...>>

I've heard of things like sandbox and ccache but I've never touched
them. Would they be good things to use all the time or are they more
for developers?

Anyway, if someone can help clear this up I would appreciate it.

Thanks,
Mark
-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Chris Brennan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm not a developer, but I use the following

Leviathan ~ # grep FEAT /etc/make.conf
FEATURES="parallel-fetch distclean ccache confcache"
Leviathan ~ #

For the average user, these are a safe bet, the last two are apps you'll
need to emerge and set up as well. pretty simple and straight forward.

Mark Knecht wrote:
| On Fri, Mar 7, 2008 at 8:09 AM, Mark Knecht <markknecht@gmail.com> wrote:
|> Hi all,
|>    What would be a sufficient set of actions for me to take to get
|>  backtrace info from Wine that would be useful to Wine devlopers? Their
|>  Bugzilla folks are are saying, correctly I think, that everything
|>  necessary is stripped out and that the info I'm providing doesn't
|>  help. I don't see anything specific in the Wine flags.
|>
|>    Is this some sort of major effort required where I have to go back
|>  and recompile many things on my system or is there a way to compile
|>  just Wine to give them what they need?
|>
|>    I found this page to read:
|>
|>  http://www.gentoo.org/proj/en/qa/backtraces.xml
|>
|>    I do not understand the nostrip/splitdebug topic. I do not find
|>  either word in man emerge or man portage. Is this a gcc thing?
|>
|>    My current gcc flags look like this:
|>
|>  CFLAGS="-march=k8 -O2 -pipe"
|>  CHOST="x86_64-pc-linux-gnu"
|>  CXXFLAGS="${CFLAGS}"
|>  MAKEOPTS="-j2"
|>
|>    Any comments about whether those are good or not for a
|>  non-developer, desktop user type like me would be appreciated. I don't
|>  mind changing cflags to get these folks what they want.
|>
|>  Thanks,
|>  Mark
|>
|
| OK, so this seems to be part of using the FEATURES=" ... " line in
make.conf.
|
| I do not have a FEATURES line at all so I'm hesitant to just start
| throwing things in. <<glug...help...>>
|
| I've heard of things like sandbox and ccache but I've never touched
| them. Would they be good things to use all the time or are they more
| for developers?
|
| Anyway, if someone can help clear this up I would appreciate it.
|
| Thanks,
| Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH0XRp8hUIAnGfls4RAi+aAKCS89m1eZ6DjvJe7SkUNgtMvYLWpgCdEsZp
58LKFc6R3KJkKJ3wr0fnayc=
=h8oX
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Mark Knecht]

On Fri, Mar 7, 2008 at 8:59 AM, Chris Brennan <xaero@xaerolimit.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  I'm not a developer, but I use the following
>
>  Leviathan ~ # grep FEAT /etc/make.conf
>  FEATURES="parallel-fetch distclean ccache confcache"
>  Leviathan ~ #
>
>  For the average user, these are a safe bet, the last two are apps you'll
>  need to emerge and set up as well. pretty simple and straight forward.
>

I'm not finding confcache or anything that's the obvious right choice
on that one. I'll emerge ccache though.

Thanks,
Mark
-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Duncan]

"Mark Knecht" <markknecht@gmail.com> posted
5bdc1c8b0803070921xbc44366we4b3d6b3d9615bfd@mail.gmail.com, excerpted
below, on  Fri, 07 Mar 2008 09:21:51 -0800:

> I'm not finding confcache or anything that's the obvious right choice on
> that one. I'll emerge ccache though.

Yeah... confcache was an experiment that has been shelved for the time 
being.  It was designed to cache the results of various config tests 
repeated for many/most ebuilds, only dumping the cache and letting them 
retest from scratch when required (if something in the build system, say 
gcc or whatever, changed).  The problem was that a number of packages put 
bad data in the cache/database, but compiled fine themselves, thereby 
leaving the bad data to be found by the next package that tried a test 
with the same data.  Since this might be the first package after or the 
100th, it was difficult to figure out where the bad data was coming from 
in ordered to fix it.  The result was basically packages failing because 
they got a bad config, with no easy way to trace it, so they just masked 
confcache.

Advanced users can still use it if they want, using package.unmask (they 
may need to find an ebuild too, as I'm not sure whether it's still in 
portage but masked, or not even there now, but it's available in the 
archives if necessary), but they have to be prepared to manually dump the 
confcache database and try again if problems appear.  I ran it for 
awhile, but after my upgrade to dual dual-cores, decided the machine was 
fast enough at running the configs that it wasn't worth the hassle any 
more, so I turned off the feature and unmerged the confcache package.

For people who'd prefer to have portage "just work" with the least 
hassle, even if it takes a bit longer on some packages, confcache is 
definitely something you want to leave alone, at least for now.  Maybe 
someday...

-- 
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@lists.gentoo.org mailing list

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

[Mark Knecht]

On Fri, Mar 7, 2008 at 10:54 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> "Mark Knecht" <markknecht@gmail.com> posted
>  5bdc1c8b0803070921xbc44366we4b3d6b3d9615bfd@mail.gmail.com, excerpted
>  below, on  Fri, 07 Mar 2008 09:21:51 -0800:
>
>
>  > I'm not finding confcache or anything that's the obvious right choice on
>  > that one. I'll emerge ccache though.
>
>  Yeah... confcache was an experiment that has been shelved for the time
>  being.

<SNIP>

>
>  For people who'd prefer to have portage "just work" with the least
>  hassle, even if it takes a bit longer on some packages, confcache is
>  definitely something you want to leave alone, at least for now.  Maybe
>  someday...
>
>  --
>  Duncan - List replies preferred.   No HTML msgs.

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.

Thanks,
Mark
-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Mark Knecht]

On Fri, Mar 7, 2008 at 11:03 AM, Mark Knecht <markknecht@gmail.com> wrote:
> On Fri, Mar 7, 2008 at 10:54 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>  > "Mark Knecht" <markknecht@gmail.com> posted
>  >  5bdc1c8b0803070921xbc44366we4b3d6b3d9615bfd@mail.gmail.com, excerpted
>  >  below, on  Fri, 07 Mar 2008 09:21:51 -0800:
>  >
>  >
>  >  > I'm not finding confcache or anything that's the obvious right choice on
>  >  > that one. I'll emerge ccache though.
>  >
>  >  Yeah... confcache was an experiment that has been shelved for the time
>  >  being.
>
>  <SNIP>
>
>
>  >
>  >  For people who'd prefer to have portage "just work" with the least
>  >  hassle, even if it takes a bit longer on some packages, confcache is
>  >  definitely something you want to leave alone, at least for now.  Maybe
>  >  someday...
>  >
>  >  --
>  >  Duncan - List replies preferred.   No HTML msgs.
>
>  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.
>
>  Thanks,
>  Mark
>
Sorry. Also added

FEATURES="parallel-fetch distclean ccache confcache splitdebug"

to make.conf
-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Duncan]

"Mark Knecht" <markknecht@gmail.com> 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 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@lists.gentoo.org mailing list

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

[Duncan]

Duncan <1i5t5.duncan@cox.net> posted pan.2008.03.08.01.15.10@cox.net,
excerpted below, on  Sat, 08 Mar 2008 01:15:10 +0000:

> 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.

I just checked, wine does appear to be 32-bit only, as it's masked on my 
no-multilib profile.  I don't know if it's binary-only or if it's 
actually built as 32-bit on multilib profiles, but it's certainly 32-bit 
only, and therefore masked by the no-multilib profile.  FWIW.



-- 
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@lists.gentoo.org mailing list

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

[Mark Knecht]

On Fri, Mar 7, 2008 at 9:06 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Duncan <1i5t5.duncan@cox.net> posted pan.2008.03.08.01.15.10@cox.net,
>  excerpted below, on  Sat, 08 Mar 2008 01:15:10 +0000:
>
>
>  > 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.
>
>  I just checked, wine does appear to be 32-bit only, as it's masked on my
>  no-multilib profile.  I don't know if it's binary-only or if it's
>  actually built as 32-bit on multilib profiles, but it's certainly 32-bit
>  only, and therefore masked by the no-multilib profile.  FWIW.
>
>
Duncan,
   Thanks for the responses. Even though they are a bit over my head
They were helpful.

   One comment about Wine. There is both Open Source software as well
as free binary distribution software for Windows, especially in the
audio area. Small signal processing units like reverb and
synthesizers, etc. Not everythign compiled for Windows is created by
the Dark Lords of the North West. Anyway, just because we run Wine
doesn't mean we have to go against your free software mantra. That's a
good portion of how I've used Wine in the past. Other than that I try,
once in awhile, to run a game which I've already purchased. Not the
best, I know, but better than continuing to purchase, or at least I
think so. To each his/her own.

   I ended up doing two things:

1) I built Wine using the nostrip feature. This did not produce
anything extra in the output. Maybe I'm somehow not taking the most
advantage, I don't know.

2) I built Wine using the WineHQ.org tarball but didn't install it. I
then ran it from its build directory. This worked fine and produced
backtrace data that the folks on the Wine list say looks pretty good
and should be helpful.

   Again, and as always, I really appreciate all your inputs. They are
often enlightening!

Cheers,
Mark
-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Duncan]

"Mark Knecht" <markknecht@gmail.com> posted
5bdc1c8b0803081040k3e83bd5oe583f4b299b68674@mail.gmail.com, excerpted
below, on  Sat, 08 Mar 2008 10:40:49 -0800:

> One comment about Wine. There is both Open Source software as well as
> free binary distribution software for Windows, especially in the audio
> area. Small signal processing units like reverb and synthesizers, etc.
> Not everythign compiled for Windows is created by the Dark Lords of the
> North West. Anyway, just because we run Wine doesn't mean we have to go
> against your free software mantra. That's a good portion of how I've
> used Wine in the past. Other than that I try, once in awhile, to run a
> game which I've already purchased. Not the best, I know, but better than
> continuing to purchase, or at least I think so. To each his/her own.

Agreed.  

FWIW I've mentioned in the past that I have an old non-freedomware game I 
still run, Master of Orion, original DOS edition, using DOSBOX.  I'm not 
proud of it but do admit that I'm pretty much its slave, as I'm basically 
addicted, tho I can take some comfort in the fact that it's now a decade 
and a half (copywrite 1993 and that was the update I got) old.

As for freedomware designed to run on MS Windows, yes, it does exist.  
However, the platform itself isn't free (of course), and running apps 
thru WINE is sort of like trying to drive from the back seat of a bus 
using planks to control the steering and acceleration.  It may be 
possible, but if one can sit in the driver's seat (run a native Linux 
application doing the same thing, better and faster), it's useful to do 
so. =8^)  I do recognize that choice isn't available for everyone, but 
since I have it for everything I need to run (with that single game 
exception), I take advantage of it.  If you note, I described what I 
choose to do; I didn't claim what you did was wrong for you, but am 
simply glad that I can get away without it, even if it involves a bit of 
pain at times (running gnash or swfdec for flash, for instance, and doing 
without where it fails to work).  It /does/ significantly decomplicate 
the system side of things, since I can and do run nomultilib now. =8^)

-- 
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@lists.gentoo.org mailing list