Re: Some fixes in capabilities

[Andreas Mohr]

On Tue, Nov 26, 2002 at 10:23:55PM +0100, Lionel Ulmer wrote:
> Hi all,
>
> As long as we do not support multi-texturing in our D3D driver, fill the
> caps properly. Now SS2 does not try to do multitexturing anymore (not that
> it actually works now, it's just that it would break less :-) ).
>
> Note: is there a way from DLL X to activate relay debugging ? What happens
>       is that SS2 somehow freezes at one point and doing a relay trace from
>       the start is about a 3 GB file... So what I would like to do is at a
>       specific function in the D3D code that I know to be just before the
>       freeze, call 'activate relay' and voila, I have relaying on :-) (to be
>       able to do that for all DLLs would be even better).
>   But well, considering DLL separation and all that, I doubt that this
>   would be possible :-/

Oh pleeeeze... I thought that at least the Wine developers are reading
the wine docu properly... ;-)

Let's see... first you use completely inacceptable words, and then
you admit to never reading the docu... bad, bad, very bad guy. :)

Read wine.man. It explains how to do relay logging for a single DLL.
Although I'm afraid that this might actually be broken at the moment
maybe :-\

Some fixes in capabilities

[Lionel Ulmer]

> Oh pleeeeze... I thought that at least the Wine developers are reading
> the wine docu properly... ;-)

You should know now that developpers are the one that read the
documentations the less :-)
> Read wine.man. It explains how to do relay logging for a single DLL.
> Although I'm afraid that this might actually be broken at the moment
> maybe :-\

I do not want to turn on relaying for only one DLL (as I have no clue at all
where the problem is)... What I want is to turn on relaying for all DLLs
*after* the program has started (and *from* one of Wine's DLL and not from
the loader or any other 'special' code).

Ie, the program starts, loads the level / stuff for 10 minutes (and whould
have produced a 2.5 GB log unreadable without big file support) and then
only the last 10 seconds are important. So I would like to only relay these.

Lionel

Some fixes in capabilities

[Alexandre Julliard]

Lionel Ulmer  writes:
> Ie, the program starts, loads the level / stuff for 10 minutes (and whould
> have produced a 2.5 GB log unreadable without big file support) and then
> only the last 10 seconds are important. So I would like to only relay these.

The easy way would be to print some magic string at that point, and
pipe the output into a sed that deletes everything before that
string. It will still be a bit slow though.

The harder way is to call wine_dbg_parse_options("+relay"). This would
work for a normal debugging option, but for relay there is some work
that needs to be done at startup so you need to handle that too. A way
would be to start with +relay, turn it off with wine_dbg_parse_options,
and then turn it on again when needed.

Some fixes in capabilities

[Tony Lambregts]

Alexandre Julliard wrote:
> Lionel Ulmer  writes:
> > Ie, the program starts, loads the level / stuff for 10 minutes (and whould
> > have produced a 2.5 GB log unreadable without big file support) and then
> > only the last 10 seconds are important. So I would like to only relay these.
>
> The easy way would be to print some magic string at that point, and
> pipe the output into a sed that deletes everything before that
> string. It will still be a bit slow though.
>
> The harder way is to call wine_dbg_parse_options("+relay"). This would
> work for a normal debugging option, but for relay there is some work
> that needs to be done at startup so you need to handle that too. A way
> would be to start with +relay, turn it off with wine_dbg_parse_options,
> and then turn it on again when needed.

As Lionels problem is not by any means unique Iwould think that this 
should be documented somewhere. I was thinking of adding a section to 
the wine developers guide along the lines of (semi) Advanced Debuging 
Techniques. This section would include how to put a  breakpoint for some 
complex condition into the code.  and  adding some a magic strings to 
trace logs.

While I am on the subject: as I mentioned in my other mail on this 
subject. Turning on gdi in winedbg (or any other channel/api that the 
debugger uses) will include calls from winedebug as well as the program 
I am debugging. This is an unhelpfull situation.

I think it would be helpfull to change this behavior so that calls from 
winedbg messages do not get logged along with the programs. Is this 
possible and if so is it something that someone as faint-of-skill as 
myself would be able to tackle. Pointers, Comments, Flames...?

Some fixes in capabilities

[Eric Pouech]

> While I am on the subject: as I mentioned in my other mail on this
> subject. Turning on gdi in winedbg (or any other channel/api that the
> debugger uses) will include calls from winedebug as well as the program
> I am debugging. This is an unhelpfull situation.

are you sure of this ? debug channels are only changed in the debugged
app, not in the debugger
aren't you looking at different threads ?

A+

Some fixes in capabilities

[Tony Lambregts]

Eric Pouech wrote:
> > While I am on the subject: as I mentioned in my other mail on this
> > subject. Turning on gdi in winedbg (or any other channel/api that the
> > debugger uses) will include calls from winedebug as well as the program
> > I am debugging. This is an unhelpfull situation.
>
> are you sure of this ? debug channels are only changed in the debugged
> app, not in the debugger
> aren't you looking at different threads ?

My appologies. (I am a VERY thick at times) I think most of my problems 
with this is that I am/was doing it (The Wrong Way) (C) OK. I think I 
should clarify since I brought it up  There are two ways of getting 
extraneous messages from winedbg in the log.

1). Starting winedbg with --debugmsg +(any channel you want a trace of) 
ie: +loaddll

2). Any fixme message will get into the log regardless of whether it is 
generated trough the app or winedbg. I would assume this also applies to 
err and warn as well but I have not tested them

I think that now that I know about these two conditions (and avoid them) 
I should be able to get a good clean log.

Latest wine cvs error

[Boris]

I tried compiling the latest cvs and heres the error I get.

make[2]: Leaving directory `/root/wine/tools/wrc'

make[1]: Leaving directory `/root/wine/tools'

make[1]: Entering directory `/root/wine/dlls'

make[2]: Entering directory `/root/wine/dlls/ntdll'

make[3]: Entering directory `/root/wine/dlls/ntdll/tests'

LD_LIBRARY_PATH="../../../library:../../../unicode:$LD_LIBRARY_PATH"

../../../tools/winebuild/winebuild -fPIC -DSTRICT -DNONAMELESSUNION

-DNONAMELESSSTRUCT -o

ntdll_test.exe.spec.c -exe ntdll_test.exe -mcui error.o generated.o

rtlbitmap.o rtlstr.o testlist.o -L../../../dlls -L.. -lntdll

could not open .so file for kernel32.dll

make[3]: *** [ntdll_test.exe.spec.c] Error 1

make[3]: Leaving directory `/root/wine/dlls/ntdll/tests'

make[2]: *** [tests] Error 2

make[2]: Leaving directory `/root/wine/dlls/ntdll'

make[1]: *** [ntdll] Error 2

make[1]: Leaving directory `/root/wine/dlls'

make: *** [dlls] Error 2

Some fixes in capabilities

[Eric Pouech]

> My appologies. (I am a VERY thick at times) I think most of my problems
> with this is that I am/was doing it (The Wrong Way) (C) OK. I think I
> should clarify since I brought it up  There are two ways of getting
> extraneous messages from winedbg in the log.
>
> 1). Starting winedbg with --debugmsg +(any channel you want a trace of)
> ie: +loaddll
> 2). Any fixme message will get into the log regardless of whether it is
> generated trough the app or winedbg. I would assume this also applies to
> err and warn as well but I have not tested them

this would apply to fixme and err which are turned on by default
warn and trace are off by default
> I think that now that I know about these two conditions (and avoid them)
> I should be able to get a good clean log.

the point 2/ is complely intented and should be kept as such

regarding point 1/, what you can do is:
- start your proces with wine foo --debugmsg +blabla
- start winedbg
- in winedbg, attach to the running process (using 'walk proc' to get
the process id and 'attach pid')

A+

Some fixes in capabilities

[Sylvain Petreolle]

You know... I RTFMed the mplayer documentation maintainer some days
ago, though every mail that goes onto the users mailing list is
modified with "RTFM" in header and footer... :)))
> Oh pleeeeze... I thought that at least the Wine developers are
> reading
> the wine docu properly... ;-)
>
> Let's see... first you use completely inacceptable words, and then
> you admit to never reading the docu... bad, bad, very bad guy. :)
>
> Read wine.man. It explains how to do relay logging for a single DLL.
> Although I'm afraid that this might actually be broken at the moment
> maybe :-\

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com