gamedevlists-windows — List for discussing game development on the Windows platform

RE: [GD-Windows] VC.NET 'Optimization'

[Grills, J. <jg...@so...>]

Perhaps I missed something earlier on since I haven't been following
this thread that closely, but I don't see your point.  Looking at the
two code statements quoted:

	timer.Restart();
	printf( "time=3D%f, result=3D%d\n", timer.GetElapsed(),
fibonacci(42));

The compiler could call the functions in this order:

	timer.Restart()
	timer.GetElapsed()
	fibonacci()
	printf()

Or it could call them in this order:

	timer.Restart()
	fibonacci()
	timer.GetElapsed()
	printf()

Only the latter one would have the timer include the fibonacci() call
time, because it's made between the timer.Restart() and
timer.GetElapsed().

To be safe, as you said, the fibonacci() call would have to be made in a
statement after the timer.Restart() but before the printf() containing
the timer.GetElapsed();

j

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Lewin, Gareth
Sent: Tuesday, April 12, 2005 4:12 PM
To: gam...@li...
Subject: RE: [GD-Windows] VC.NET 'Optimization'

Again, the order doesn't matter, the fib function has no side effects.

His goal in this specific case is to measure the speed of his fib
function, so contextually changing the order the params are passed will
work.

If the order mattered, then fib would have been called outside the
printf scope.=20

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Grills, Jeff
Sent: Tuesday, April 12, 2005 12:17 PM
To: gam...@li...
Subject: RE: [GD-Windows] VC.NET 'Optimization'


Maybe on some compilers, but it's not guaranteed.  The order of argument
evaluation to functions is not specified by the C++ standard - it's left
up to the implementations.

j

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Lewin, Gareth
Sent: Tuesday, April 12, 2005 2:02 PM
To: gam...@li...
Subject: RE: [GD-Windows] VC.NET 'Optimization'

I fail to see why this worries you, the optimiser is making a (valid)
assumption about your code, and generating the fastest sequence it can.

As a side note, just flip the order of your params to printf, that
should give you want you want.=20

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
yogiwp
Sent: Tuesday, April 12, 2005 11:52 AM
To: gam...@li...
Subject: Re: [GD-Windows] VC.NET 'Optimization'

> ----------------------------------------------------
>     timer.Restart();
>     printf( "time=3D%f, result=3D%d\n", timer.GetElapsed(), =
fibonacci(42)=20
> );
> ----------------------------------------------------

RE: [GD-Windows] VC.NET 'Optimization'

[Lewin, G. <gl...@ea...>]

Again, the order doesn't matter, the fib function has no side effects.

His goal in this specific case is to measure the speed of his fib
function, so contextually changing the order the params are passed will
work.

If the order mattered, then fib would have been called outside the
printf scope.=20

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Grills, Jeff
Sent: Tuesday, April 12, 2005 12:17 PM
To: gam...@li...
Subject: RE: [GD-Windows] VC.NET 'Optimization'


Maybe on some compilers, but it's not guaranteed.  The order of argument
evaluation to functions is not specified by the C++ standard - it's left
up to the implementations.

j

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Lewin, Gareth
Sent: Tuesday, April 12, 2005 2:02 PM
To: gam...@li...
Subject: RE: [GD-Windows] VC.NET 'Optimization'

I fail to see why this worries you, the optimiser is making a (valid)
assumption about your code, and generating the fastest sequence it can.

As a side note, just flip the order of your params to printf, that
should give you want you want.=20

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
yogiwp
Sent: Tuesday, April 12, 2005 11:52 AM
To: gam...@li...
Subject: Re: [GD-Windows] VC.NET 'Optimization'

> ----------------------------------------------------
>     timer.Restart();
>     printf( "time=3D%f, result=3D%d\n", timer.GetElapsed(), =
fibonacci(42)=20
> );
> ----------------------------------------------------


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid
reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU5

RE: [GD-Windows] VC.NET 'Optimization'

[Grills, J. <jg...@so...>]

Maybe on some compilers, but it's not guaranteed.  The order of argument
evaluation to functions is not specified by the C++ standard - it's left
up to the implementations.

j

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Lewin, Gareth
Sent: Tuesday, April 12, 2005 2:02 PM
To: gam...@li...
Subject: RE: [GD-Windows] VC.NET 'Optimization'

I fail to see why this worries you, the optimiser is making a (valid)
assumption about your code, and generating the fastest sequence it can.

As a side note, just flip the order of your params to printf, that
should give you want you want.=20

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
yogiwp
Sent: Tuesday, April 12, 2005 11:52 AM
To: gam...@li...
Subject: Re: [GD-Windows] VC.NET 'Optimization'

> ----------------------------------------------------
>     timer.Restart();
>     printf( "time=3D%f, result=3D%d\n", timer.GetElapsed(), =
fibonacci(42)=20
> );
> ----------------------------------------------------

RE: [GD-Windows] VC.NET 'Optimization'

[Mat N. \(BUNGIE\) <mat...@mi...>]

What worries you? The compiler optimizing out essentially dead code, or
the optimization pass that destroys trivial profiling code?

MSN
-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
yogiwp
Sent: Tuesday, April 12, 2005 11:52 AM
To: gam...@li...
Subject: Re: [GD-Windows] VC.NET 'Optimization'

----- Original Message -----=20
From: Kent Quirk=20

> fib is declared locally, and no one ever takes its address. The
compiler is pretty safe in assuming=20
> that no sane code could possibly affect the value of fib. Similarly,
the fibonacci function only=20
> takes a constant argument. If it's in the same source file, it might
even know that the function has=20
> no aliasing issues. Consequently, it's reasonable to optimize away the
creation of the fib variable=20
> and simply embed the function call in the printf call.
>=20
> My guess is that what the compiler did was optimize this to:
>=20
> ----------------------------------------------------
>     timer.Restart();
>     printf( "time=3D%f, result=3D%d\n", timer.GetElapsed(), =
fibonacci(42)
);
> ----------------------------------------------------

Yes, this is exactly what happened (disassembly below).
Sigh. I must say that this makes my worry.

Btw, #pragma optimize("a",off) and/or ("w",off) have no effect; it's
still generating the exact same code. Declaring msTime as 'volatile'
does fix it.

------------------------------------------------------------------------
-------
; 5215 :    timer.Restart();

    lea ecx, DWORD PTR _timer$[esp+148]
    call    ?Restart@CRealTimer@Torture@@QAEXXZ ;
Torture::CRealTimer::Restart

; 5216 :    int fib =3D fibonacci( 42 );
; 5217 :    float msTime =3D timer.GetElapsed();

    lea ecx, DWORD PTR _timer$[esp+148]
    call    ?GetElapsed@CRealTimer@Torture@@QAEMXZ  ;
Torture::CRealTimer::GetElapsed
    push    41                  ; 00000029H
    call    ?fibonacci@@YAHH@Z          ; fibonacci
    push    40                  ; 00000028H
    mov edx, eax
    call    ?fibonacci@@YAHH@Z          ; fibonacci
    add esp, 8
    add edx, eax

; 5218 :    printf( "msTime=3D%f, result=3D%d\n", msTime, fib );

    push    edx
    sub esp, 8
    fstp    QWORD PTR [esp]
    push    OFFSET
FLAT:??_C@_0BG@BEAEGCGA@msTime?$DN?$CFf?0?5result?$DN?$CFd?6?$AA@
    call    _printf
    add esp, 16                 ; 00000010H
------------------------------------------------------------------------
-------
(There are 2 fibonacci() calls because of inlining -- fibonacci() is a
recursive function calling itself twice.)


Yogi Wahyu Prasidha



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D555

RE: [GD-Windows] VC.NET 'Optimization'

[Lewin, G. <gl...@ea...>]

I fail to see why this worries you, the optimiser is making a (valid)
assumption about your code, and generating the fastest sequence it can.

As a side note, just flip the order of your params to printf, that
should give you want you want.=20

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
yogiwp
Sent: Tuesday, April 12, 2005 11:52 AM
To: gam...@li...
Subject: Re: [GD-Windows] VC.NET 'Optimization'

----- Original Message -----
From: Kent Quirk=20

> fib is declared locally, and no one ever takes its address. The=20
> compiler is pretty safe in assuming that no sane code could possibly=20
> affect the value of fib. Similarly, the fibonacci function only takes=20
> a constant argument. If it's in the same source file, it might even=20
> know that the function has no aliasing issues. Consequently, it's
reasonable to optimize away the creation of the fib variable and simply
embed the function call in the printf call.
>=20
> My guess is that what the compiler did was optimize this to:
>=20
> ----------------------------------------------------
>     timer.Restart();
>     printf( "time=3D%f, result=3D%d\n", timer.GetElapsed(), =
fibonacci(42)=20
> );
> ----------------------------------------------------

Yes, this is exactly what happened (disassembly below).
Sigh. I must say that this makes my worry.

Btw, #pragma optimize("a",off) and/or ("w",off) have no effect; it's
still generating the exact same code. Declaring msTime as 'volatile'
does fix it.

------------------------------------------------------------------------
-------
; 5215 :    timer.Restart();

    lea ecx, DWORD PTR _timer$[esp+148]
    call    ?Restart@CRealTimer@Torture@@QAEXXZ ;
Torture::CRealTimer::Restart

; 5216 :    int fib =3D fibonacci( 42 );
; 5217 :    float msTime =3D timer.GetElapsed();

    lea ecx, DWORD PTR _timer$[esp+148]
    call    ?GetElapsed@CRealTimer@Torture@@QAEMXZ  ;
Torture::CRealTimer::GetElapsed
    push    41                  ; 00000029H
    call    ?fibonacci@@YAHH@Z          ; fibonacci
    push    40                  ; 00000028H
    mov edx, eax
    call    ?fibonacci@@YAHH@Z          ; fibonacci
    add esp, 8
    add edx, eax

; 5218 :    printf( "msTime=3D%f, result=3D%d\n", msTime, fib );

    push    edx
    sub esp, 8
    fstp    QWORD PTR [esp]
    push    OFFSET
FLAT:??_C@_0BG@BEAEGCGA@msTime?$DN?$CFf?0?5result?$DN?$CFd?6?$AA@
    call    _printf
    add esp, 16                 ; 00000010H
------------------------------------------------------------------------
-------
(There are 2 fibonacci() calls because of inlining -- fibonacci() is a
recursive function calling itself twice.)


Yogi Wahyu Prasidha



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid
reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D555

Re: [GD-Windows] VC.NET 'Optimization'

[yogiwp <yo...@gm...>]

----- Original Message ----- 
From: Kent Quirk 

> fib is declared locally, and no one ever takes its address. The compiler is pretty safe in assuming 
> that no sane code could possibly affect the value of fib. Similarly, the fibonacci function only 
> takes a constant argument. If it's in the same source file, it might even know that the function has 
> no aliasing issues. Consequently, it's reasonable to optimize away the creation of the fib variable 
> and simply embed the function call in the printf call.
> 
> My guess is that what the compiler did was optimize this to:
> 
> ----------------------------------------------------
>     timer.Restart();
>     printf( "time=%f, result=%d\n", timer.GetElapsed(), fibonacci(42) );
> ----------------------------------------------------

Yes, this is exactly what happened (disassembly below).
Sigh. I must say that this makes my worry.

Btw, #pragma optimize("a",off) and/or ("w",off) have no effect; it's
still generating the exact same code. Declaring msTime as 'volatile'
does fix it.

-------------------------------------------------------------------------------
; 5215 :    timer.Restart();

    lea ecx, DWORD PTR _timer$[esp+148]
    call    ?Restart@CRealTimer@Torture@@QAEXXZ ; Torture::CRealTimer::Restart

; 5216 :    int fib = fibonacci( 42 );
; 5217 :    float msTime = timer.GetElapsed();

    lea ecx, DWORD PTR _timer$[esp+148]
    call    ?GetElapsed@CRealTimer@Torture@@QAEMXZ  ; Torture::CRealTimer::GetElapsed
    push    41                  ; 00000029H
    call    ?fibonacci@@YAHH@Z          ; fibonacci
    push    40                  ; 00000028H
    mov edx, eax
    call    ?fibonacci@@YAHH@Z          ; fibonacci
    add esp, 8
    add edx, eax

; 5218 :    printf( "msTime=%f, result=%d\n", msTime, fib );

    push    edx
    sub esp, 8
    fstp    QWORD PTR [esp]
    push    OFFSET FLAT:??_C@_0BG@BEAEGCGA@msTime?$DN?$CFf?0?5result?$DN?$CFd?6?$AA@
    call    _printf
    add esp, 16                 ; 00000010H
-------------------------------------------------------------------------------
(There are 2 fibonacci() calls because of inlining -- fibonacci() is a
recursive function calling itself twice.)


Yogi Wahyu Prasidha

RE: [GD-Windows] VC.NET 'Optimization'

[Jon W. <hp...@mi...>]

> If it's in the same source file, it might even know that the function 
> has no aliasing issues. 

I think this is the key -- it couldn't know whether the functions used 
internally to the timer instance would be aliased by fibonacci() unless 
it had the source to that function.

Did you look at the assembly? It might even be that the compiler 
replaces the call to the function with a pre-calculated value, as it's 
entirely constant. That would surprise me less than a function call 
re-ordering optimization...

Cheers,

			/ h+

RE: [GD-Windows] VC.NET 'Optimization'

[Kent Q. <ken...@co...>]

I think this is pretty common, actually. Look:

----------------------------------------------------
     timer.Restart();
     int fib = fibonacci( 42 );
     float msTime = timer.GetElapsed();
     printf( "time=%f, result=%d\n", msTime, fib );
----------------------------------------------------

fib is declared locally, and no one ever takes its address. The compiler is 
pretty safe in assuming that no sane code could possibly affect the value 
of fib. Similarly, the fibonacci function only takes a constant argument. 
If it's in the same source file, it might even know that the function has 
no aliasing issues. Consequently, it's reasonable to optimize away the 
creation of the fib variable and simply embed the function call in the 
printf call.

My guess is that what the compiler did was optimize this to:

----------------------------------------------------
     timer.Restart();
     printf( "time=%f, result=%d\n", timer.GetElapsed(), fibonacci(42) );
----------------------------------------------------

MSVC has this:


No aliasing
/Oa:  Assume no aliasing occurs within functions. Alternate: #pragma 
optimize("a")

Intra-func aliasing
/Ow: Assume aliasing occurs across function calls. Alternate: #pragma 
optimize("w")

         Kent


At 06:24 PM 4/11/2005, you wrote:


> > BTW: I'm not entirely sure whether that's a compiler bug or a valid
> > optimisation - it depends what your Restart() function does.
>
>The compiler might be doing type-based aliasing to re-order the
>functions, if one uses float, and the other int, say.
>
>However, I still don't see how the compiler can do this. Timers
>call into functions that are dllimport, and those functions can
>have arbitrary side effects -- especially in a version of the
>DLL that's not released yet. Thus, no amount of alias analysis
>can allow the compiler to re-order the operations like that, so
>I'd say it's a real bug.
>
>Now, if it's really a bug, how come we're not seeing this all
>over the place? Seems like it would cause pretty much nothing at
>all to actually work...
>
>Cheers,
>
>                         / h+

----
Kent Quirk
CTO, CogniToy

RE: [GD-Windows] VC.NET 'Optimization'

[Jon W. <hp...@mi...>]

> BTW: I'm not entirely sure whether that's a compiler bug or a valid
> optimisation - it depends what your Restart() function does.

The compiler might be doing type-based aliasing to re-order the
functions, if one uses float, and the other int, say.

However, I still don't see how the compiler can do this. Timers 
call into functions that are dllimport, and those functions can 
have arbitrary side effects -- especially in a version of the 
DLL that's not released yet. Thus, no amount of alias analysis 
can allow the compiler to re-order the operations like that, so 
I'd say it's a real bug.

Now, if it's really a bug, how come we're not seeing this all 
over the place? Seems like it would cause pretty much nothing at 
all to actually work...

Cheers,

			/ h+

RE: [GD-Windows] VC.NET 'Optimization'

[Simon O'C. <si...@sc...>]

Simply re-ordering the source without forcing optimisations off isn't
guaranteed to do what you expect. Contrived example: imagine your =
profiling
code calls QueryPerformanceFrequency() and then code being profiled =
later on
makes a call to QueryPerformanceFrequency(); it's feasible that an =
optimiser
could detect two calls to that same Windows function and optimise them =
into
one call thus totally skewing your results.

Personally (when not using an already proven profiler) I'd always =
declare
the timer object and even msTime as "volatile" to ensure the compiler
doesn't consider them for optimization.=20

Alternatively you can use #pragma optimize to control exactly which code
does and doesn=92t get optimised.=20

BTW: I'm not entirely sure whether that's a compiler bug or a valid
optimisation - it depends what your Restart() function does.


> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of yogiwp
> Sent: 11 April 2005 14:47
> To: gam...@li...
> Subject: [GD-Windows] VC.NET 'Optimization'
>=20
> Hi all,
>=20
> I've just waste alot of time debugging, and surprised that=20
> the root of problem come from VC.NET 2003 reordering stuff=20
> too aggresively.
>=20
> This piece of code is supposed to measure time spent in fibonacci():
> ----------------------------------------------------
>     timer.Restart();
>     int fib =3D fibonacci( 42 );
>     float msTime =3D timer.GetElapsed();
>     printf( "time=3D%f, result=3D%d\n", msTime, fib );
> ----------------------------------------------------
> But the optimizer decided to move the fibonacci() call just before
> printf() and after GetElapsed(), causing the timer to measure nothing.
>=20
> Of course the bug does not manifest in debug builds, which=20
> made my head hurt even more :(
>=20
> The fix is simply changing the last line to:
>     printf( "time=3D%f, result=3D%d\n", timer.GetElapsed(), fib );
>=20
> Anyone got bitten by this before? This is a bug, right?
>=20
>=20
> Yogi Wahyu Prasidha
>=20
>=20
>=20
>=20

--=20
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.6 - Release Date: 11/04/2005
=20

RE: [GD-Windows] VC.NET 'Optimization'

[Ken N. <kn...@wh...>]

Yeah, I have and there is no immediate fix around this unless you want
to turn all optimizations off(hence the reason it works fine in debug
mode).=20

-Ken Noland

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
yogiwp
Sent: Monday, April 11, 2005 9:47 AM
To: gam...@li...
Subject: [GD-Windows] VC.NET 'Optimization'

Hi all,

I've just waste alot of time debugging, and surprised that the root of
problem come from VC.NET 2003 reordering stuff too aggresively.

This piece of code is supposed to measure time spent in fibonacci():
----------------------------------------------------
    timer.Restart();
    int fib =3D fibonacci( 42 );
    float msTime =3D timer.GetElapsed();
    printf( "time=3D%f, result=3D%d\n", msTime, fib );
----------------------------------------------------
But the optimizer decided to move the fibonacci() call just before
printf() and after GetElapsed(), causing the timer to measure nothing.

Of course the bug does not manifest in debug builds, which made
my head hurt even more :(

The fix is simply changing the last line to:
    printf( "time=3D%f, result=3D%d\n", timer.GetElapsed(), fib );

Anyone got bitten by this before? This is a bug, right?


Yogi Wahyu Prasidha




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D555

[GD-Windows] VC.NET 'Optimization'

[yogiwp <yo...@gm...>]

Hi all,

I've just waste alot of time debugging, and surprised that the root of
problem come from VC.NET 2003 reordering stuff too aggresively.

This piece of code is supposed to measure time spent in fibonacci():
----------------------------------------------------
    timer.Restart();
    int fib = fibonacci( 42 );
    float msTime = timer.GetElapsed();
    printf( "time=%f, result=%d\n", msTime, fib );
----------------------------------------------------
But the optimizer decided to move the fibonacci() call just before
printf() and after GetElapsed(), causing the timer to measure nothing.

Of course the bug does not manifest in debug builds, which made
my head hurt even more :(

The fix is simply changing the last line to:
    printf( "time=%f, result=%d\n", timer.GetElapsed(), fib );

Anyone got bitten by this before? This is a bug, right?


Yogi Wahyu Prasidha

RE: [GD-Windows] distcc/ccache with MSVC

[Dr A. P. <aj...@eu...>]

Glad to hear! Keep us posted on your success.
Regards,
Andrew

>-----Original Message-----
>From: gam...@li...
>[mailto:gam...@li...]On Behalf Of
>Alen Ladavac
>Sent: 25 March 2005 09:06
>To: gam...@li...
>Subject: Re: [GD-Windows] distcc/ccache with MSVC
>
>
>Thnaks for the idea! I've made a relatively simple wrapper and it seems to
>work now. Had to re-route stdout, recognize /cygdrive/d/ paths that
>distcc/ccache sometimes pass on to the compiler and remap them into d:\
>paths, and to remap the -o into /Fo.
>
>----- Original Message -----
>From: "Dr Andrew Perella" <aj...@eu...>
>To: <gam...@li...>
>Sent: Thursday, March 24, 2005 08:56
>Subject: RE: [GD-Windows] distcc/ccache with MSVC
>
>
>> Why not just wrap cl.exe in another cl.exe that doesn't pass on stdout.
>>
>> >-----Original Message-----
>> >From: gam...@li...
>> >[mailto:gam...@li...]On Behalf Of
>> >Alen Ladavac
>> >Sent: 24 March 2005 09:31
>> >To: gam...@li...
>> >Subject: Re: [GD-Windows] distcc/ccache with MSVC
>> >
>> >
>> >Kind of speaking to myself, but....
>> >
>> >I've found what is the problem here:
>> >
>> >> Btw, interestingly enough, cl.exe version 7.1 happily understands -E
>> >and -c.
>> >> Still, no luck even if using it directly(I.e. ccache cl.exe -c
>hello.c).
>> >It
>> >> produces output, but doesn't go through cache.
>> >
>> >Seems like it would work if cl.exe wasn't printing to stdout. Ccache logs
>> >"Compiler produced stdout" and refuses to cache the result. Can't find
>how
>> >to disable the "feature" of cl.exe that it prints the name of the source
>it
>> >compiles. :/
>> >
>> >
>> >----- Original Message -----
>> >From: "Alen Ladavac" <ale...@cr...>
>> >To: <gam...@li...>
>> >Sent: Thursday, March 24, 2005 08:09
>> >Subject: [GD-Windows] distcc/ccache with MSVC
>> >
>> >
>> >> Hi all,
>> >>
>> >> Has anyone had success with using distcc and/or ccache with MSVC
>> >compilers.
>> >> We are targeting .NET2003, what would be MSVC7.1, but any experience or
>> >> suggestions even with the older versions would help.
>> >>
>> >> So far, I have managed to extract distcc and ccache from cygwin and
>> >download
>> >> wrapmsvc.exe, from the Coin3D project. Allegedly, wrapmsvc.exe is
>supposed
>> >> to convert gcc-style parameters to msvc-style and call cl.exe. It seems
>to
>> >> do so, but when used with distcc/ccache, it spews something like this:
>> >>
>> >> D:\Work\Temp\ccachetest>ccache wrapmsvc -c hello.c
>> >> hello.c
>> >> /cygdrive/c/utility/wrapmsvc ERROR: unknown option
>> >> "d:\Temp\ccache/tmp.stdout.aragorn.1644.i"
>> >>
>> >> Btw, interestingly enough, cl.exe version 7.1 happily understands -E
>> >and -c.
>> >> Still, no luck even if using it directly(I.e. ccache cl.exe -c
>hello.c).
>> >It
>> >> produces output, but doesn't go through cache.
>> >>
>> >> Any ideas?
>> >>
>> >> Thanks,
>> >> Alen
>> >>
>> >>
>> >>
>> >> -------------------------------------------------------
>> >> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon
>2005
>> >> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
>> >> Embedded(r) & Windows Mobile(tm) platforms, applications & content.
>> >Register
>> >> by 3/29 & save $300
>> >http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
>> >> _______________________________________________
>> >> Gamedevlists-windows mailing list
>> >> Gam...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>> >> Archives:
>> >> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>> >>
>> >
>> >
>> >
>> >-------------------------------------------------------
>> >This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
>> >Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
>> >Embedded(r) & Windows Mobile(tm) platforms, applications & content.
>Register
>> >by 3/29 & save $300
>http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
>> >_______________________________________________
>> >Gamedevlists-windows mailing list
>> >Gam...@li...
>> >https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>> >Archives:
>> >http://sourceforge.net/mailarchive/forum.php?forum_id=555
>> >
>> >_____________________________________________________________________
>> >This e-mail is confidential and may be privileged. It may be read, copied
>and used only by the intended
>> >recipient. No communication sent by e-mail to or from Eutechnyx is
>intended to give rise to contractual or
>> >other legal liability, apart from liability which cannot be excluded
>under English law.
>> >
>> >This message has been checked for all known viruses by Star Internet
>delivered through the MessageLabs Virus
>> >Control Centre.
>> >
>> >www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322
>>
>> _____________________________________________________________________
>> This e-mail is confidential and may be privileged. It may be read, copied
>and used only by the intended recipient. No communication sent by e-mail to
>or from Eutechnyx is intended to give rise to contractual or other legal
>liability, apart from liability which cannot be excluded under English law.
>>
>> This message has been checked for all known viruses by Star Internet
>delivered through the MessageLabs Virus Control Centre.
>>
>> www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
>> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
>> Embedded(r) & Windows Mobile(tm) platforms, applications & content.
>Register
>> by 3/29 & save $300
>http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
>> _______________________________________________
>> Gamedevlists-windows mailing list
>> Gam...@li...
>> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Gamedevlists-windows mailing list
>Gam...@li...
>https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>Archives:
>http://sourceforge.net/mailarchive/forum.php?forum_id=555
>
>_____________________________________________________________________
>This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended 
>recipient. No communication sent by e-mail to or from Eutechnyx is intended to give rise to contractual or 
>other legal liability, apart from liability which cannot be excluded under English law. 
>
>This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus 
>Control Centre. 
>
>www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322
>

_____________________________________________________________________
This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. No communication sent by e-mail to or from Eutechnyx is intended to give rise to contractual or other legal liability, apart from liability which cannot be excluded under English law. 

This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. 

www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322

Re: [GD-Windows] distcc/ccache with MSVC

[Alen L. <ale...@cr...>]

Thnaks for the idea! I've made a relatively simple wrapper and it seems to
work now. Had to re-route stdout, recognize /cygdrive/d/ paths that
distcc/ccache sometimes pass on to the compiler and remap them into d:\
paths, and to remap the -o into /Fo.

----- Original Message -----
From: "Dr Andrew Perella" <aj...@eu...>
To: <gam...@li...>
Sent: Thursday, March 24, 2005 08:56
Subject: RE: [GD-Windows] distcc/ccache with MSVC


> Why not just wrap cl.exe in another cl.exe that doesn't pass on stdout.
>
> >-----Original Message-----
> >From: gam...@li...
> >[mailto:gam...@li...]On Behalf Of
> >Alen Ladavac
> >Sent: 24 March 2005 09:31
> >To: gam...@li...
> >Subject: Re: [GD-Windows] distcc/ccache with MSVC
> >
> >
> >Kind of speaking to myself, but....
> >
> >I've found what is the problem here:
> >
> >> Btw, interestingly enough, cl.exe version 7.1 happily understands -E
> >and -c.
> >> Still, no luck even if using it directly(I.e. ccache cl.exe -c
hello.c).
> >It
> >> produces output, but doesn't go through cache.
> >
> >Seems like it would work if cl.exe wasn't printing to stdout. Ccache logs
> >"Compiler produced stdout" and refuses to cache the result. Can't find
how
> >to disable the "feature" of cl.exe that it prints the name of the source
it
> >compiles. :/
> >
> >
> >----- Original Message -----
> >From: "Alen Ladavac" <ale...@cr...>
> >To: <gam...@li...>
> >Sent: Thursday, March 24, 2005 08:09
> >Subject: [GD-Windows] distcc/ccache with MSVC
> >
> >
> >> Hi all,
> >>
> >> Has anyone had success with using distcc and/or ccache with MSVC
> >compilers.
> >> We are targeting .NET2003, what would be MSVC7.1, but any experience or
> >> suggestions even with the older versions would help.
> >>
> >> So far, I have managed to extract distcc and ccache from cygwin and
> >download
> >> wrapmsvc.exe, from the Coin3D project. Allegedly, wrapmsvc.exe is
supposed
> >> to convert gcc-style parameters to msvc-style and call cl.exe. It seems
to
> >> do so, but when used with distcc/ccache, it spews something like this:
> >>
> >> D:\Work\Temp\ccachetest>ccache wrapmsvc -c hello.c
> >> hello.c
> >> /cygdrive/c/utility/wrapmsvc ERROR: unknown option
> >> "d:\Temp\ccache/tmp.stdout.aragorn.1644.i"
> >>
> >> Btw, interestingly enough, cl.exe version 7.1 happily understands -E
> >and -c.
> >> Still, no luck even if using it directly(I.e. ccache cl.exe -c
hello.c).
> >It
> >> produces output, but doesn't go through cache.
> >>
> >> Any ideas?
> >>
> >> Thanks,
> >> Alen
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon
2005
> >> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
> >> Embedded(r) & Windows Mobile(tm) platforms, applications & content.
> >Register
> >> by 3/29 & save $300
> >http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> >> _______________________________________________
> >> Gamedevlists-windows mailing list
> >> Gam...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> >> Archives:
> >> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> >>
> >
> >
> >
> >-------------------------------------------------------
> >This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
> >Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
> >Embedded(r) & Windows Mobile(tm) platforms, applications & content.
Register
> >by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> >_______________________________________________
> >Gamedevlists-windows mailing list
> >Gam...@li...
> >https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> >Archives:
> >http://sourceforge.net/mailarchive/forum.php?forum_id=555
> >
> >_____________________________________________________________________
> >This e-mail is confidential and may be privileged. It may be read, copied
and used only by the intended
> >recipient. No communication sent by e-mail to or from Eutechnyx is
intended to give rise to contractual or
> >other legal liability, apart from liability which cannot be excluded
under English law.
> >
> >This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus
> >Control Centre.
> >
> >www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322
>
> _____________________________________________________________________
> This e-mail is confidential and may be privileged. It may be read, copied
and used only by the intended recipient. No communication sent by e-mail to
or from Eutechnyx is intended to give rise to contractual or other legal
liability, apart from liability which cannot be excluded under English law.
>
> This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Control Centre.
>
> www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
> Embedded(r) & Windows Mobile(tm) platforms, applications & content.
Register
> by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>

RE: [GD-Windows] distcc/ccache with MSVC

[Dr A. P. <aj...@eu...>]

Why not just wrap cl.exe in another cl.exe that doesn't pass on stdout.

>-----Original Message-----
>From: gam...@li...
>[mailto:gam...@li...]On Behalf Of
>Alen Ladavac
>Sent: 24 March 2005 09:31
>To: gam...@li...
>Subject: Re: [GD-Windows] distcc/ccache with MSVC
>
>
>Kind of speaking to myself, but....
>
>I've found what is the problem here:
>
>> Btw, interestingly enough, cl.exe version 7.1 happily understands -E
>and -c.
>> Still, no luck even if using it directly(I.e. ccache cl.exe -c hello.c).
>It
>> produces output, but doesn't go through cache.
>
>Seems like it would work if cl.exe wasn't printing to stdout. Ccache logs
>"Compiler produced stdout" and refuses to cache the result. Can't find how
>to disable the "feature" of cl.exe that it prints the name of the source it
>compiles. :/
>
>
>----- Original Message -----
>From: "Alen Ladavac" <ale...@cr...>
>To: <gam...@li...>
>Sent: Thursday, March 24, 2005 08:09
>Subject: [GD-Windows] distcc/ccache with MSVC
>
>
>> Hi all,
>>
>> Has anyone had success with using distcc and/or ccache with MSVC
>compilers.
>> We are targeting .NET2003, what would be MSVC7.1, but any experience or
>> suggestions even with the older versions would help.
>>
>> So far, I have managed to extract distcc and ccache from cygwin and
>download
>> wrapmsvc.exe, from the Coin3D project. Allegedly, wrapmsvc.exe is supposed
>> to convert gcc-style parameters to msvc-style and call cl.exe. It seems to
>> do so, but when used with distcc/ccache, it spews something like this:
>>
>> D:\Work\Temp\ccachetest>ccache wrapmsvc -c hello.c
>> hello.c
>> /cygdrive/c/utility/wrapmsvc ERROR: unknown option
>> "d:\Temp\ccache/tmp.stdout.aragorn.1644.i"
>>
>> Btw, interestingly enough, cl.exe version 7.1 happily understands -E
>and -c.
>> Still, no luck even if using it directly(I.e. ccache cl.exe -c hello.c).
>It
>> produces output, but doesn't go through cache.
>>
>> Any ideas?
>>
>> Thanks,
>> Alen
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
>> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
>> Embedded(r) & Windows Mobile(tm) platforms, applications & content.
>Register
>> by 3/29 & save $300
>http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
>> _______________________________________________
>> Gamedevlists-windows mailing list
>> Gam...@li...
>> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
>Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
>Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
>by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
>_______________________________________________
>Gamedevlists-windows mailing list
>Gam...@li...
>https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>Archives:
>http://sourceforge.net/mailarchive/forum.php?forum_id=555
>
>_____________________________________________________________________
>This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended 
>recipient. No communication sent by e-mail to or from Eutechnyx is intended to give rise to contractual or 
>other legal liability, apart from liability which cannot be excluded under English law. 
>
>This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus 
>Control Centre. 
>
>www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322

_____________________________________________________________________
This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. No communication sent by e-mail to or from Eutechnyx is intended to give rise to contractual or other legal liability, apart from liability which cannot be excluded under English law. 

This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. 

www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322

Re: [GD-Windows] distcc/ccache with MSVC

[Alen L. <ale...@cr...>]

Kind of speaking to myself, but....

I've found what is the problem here:

> Btw, interestingly enough, cl.exe version 7.1 happily understands -E
and -c.
> Still, no luck even if using it directly(I.e. ccache cl.exe -c hello.c).
It
> produces output, but doesn't go through cache.

Seems like it would work if cl.exe wasn't printing to stdout. Ccache logs
"Compiler produced stdout" and refuses to cache the result. Can't find how
to disable the "feature" of cl.exe that it prints the name of the source it
compiles. :/


----- Original Message -----
From: "Alen Ladavac" <ale...@cr...>
To: <gam...@li...>
Sent: Thursday, March 24, 2005 08:09
Subject: [GD-Windows] distcc/ccache with MSVC


> Hi all,
>
> Has anyone had success with using distcc and/or ccache with MSVC
compilers.
> We are targeting .NET2003, what would be MSVC7.1, but any experience or
> suggestions even with the older versions would help.
>
> So far, I have managed to extract distcc and ccache from cygwin and
download
> wrapmsvc.exe, from the Coin3D project. Allegedly, wrapmsvc.exe is supposed
> to convert gcc-style parameters to msvc-style and call cl.exe. It seems to
> do so, but when used with distcc/ccache, it spews something like this:
>
> D:\Work\Temp\ccachetest>ccache wrapmsvc -c hello.c
> hello.c
> /cygdrive/c/utility/wrapmsvc ERROR: unknown option
> "d:\Temp\ccache/tmp.stdout.aragorn.1644.i"
>
> Btw, interestingly enough, cl.exe version 7.1 happily understands -E
and -c.
> Still, no luck even if using it directly(I.e. ccache cl.exe -c hello.c).
It
> produces output, but doesn't go through cache.
>
> Any ideas?
>
> Thanks,
> Alen
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
> Embedded(r) & Windows Mobile(tm) platforms, applications & content.
Register
> by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>

[GD-Windows] distcc/ccache with MSVC

[Alen L. <ale...@cr...>]

Hi all,

Has anyone had success with using distcc and/or ccache with MSVC compilers.
We are targeting .NET2003, what would be MSVC7.1, but any experience or
suggestions even with the older versions would help.

So far, I have managed to extract distcc and ccache from cygwin and download
wrapmsvc.exe, from the Coin3D project. Allegedly, wrapmsvc.exe is supposed
to convert gcc-style parameters to msvc-style and call cl.exe. It seems to
do so, but when used with distcc/ccache, it spews something like this:

D:\Work\Temp\ccachetest>ccache wrapmsvc -c hello.c
hello.c
/cygdrive/c/utility/wrapmsvc ERROR: unknown option
"d:\Temp\ccache/tmp.stdout.aragorn.1644.i"

Btw, interestingly enough, cl.exe version 7.1 happily understands -E and -c.
Still, no luck even if using it directly(I.e. ccache cl.exe -c hello.c). It
produces output, but doesn't go through cache.

Any ideas?

Thanks,
Alen

Re: [GD-Windows] Updates in a modal dialog loop

[Brian H. <ho...@bo...>]

Doh, left out some important information.

First, the dialog is modal.  Second, it actually does its work in a 
separate thread along the lines of:

while ( !done )
{
   update_some_stuff();
   update_controls_to_reflect_changes();
}

The problem (I think) is that the updated stuff is happening in that 
separate thread, in parallel to whatever stuff the regular Windows/MFC 
dialog modal loop is doing.  It checks for cancellation periodically 
(assume that I haven't screwed up the app's synchronization with 
itself, but since I'm unsure what the sync rules are for MFC, heaven 
help me).

I'm hesitant to use a timer for this, since it's one of those "run as 
fast as you can" type things that might under/overrun a timer's 
interval.

Brian

[GD-Windows] Updates in a modal dialog loop

[Brian H. <ho...@bo...>]

I have a dialog box (MFC) that does processing and that periodically 
needs to pump the message loop so that paints, etc. can propagate.  In 
other words.  What is the right way to pump the loop?  I see that 
there's RunModalLoop(), EndModalLoop(), and ContinueModal(), but I 
don't see examples of how they're used and I'm not even sure if 
they're the right direction.

In a regular windows loop I'd do some work then call 
Get/Translate/DispatchMessage() periodically to get a similar effect, 
but there doesn't seem to be a corresponding facility here.

Thanks,

Brian

Re: [GD-Windows] Call stack

[Dan T. <da...@ar...>]

That failure case seems intuitive to me. You can grab the current 
instruction pointer all you want, its just going to change as soon as 
you get it. I ran into a little bit of this with a user threading 
library I wrote once. My guess is you are better off having written the 
25 lines yourself, anyway. And the stack pointer is going to be from 
within the API call, I'd guess.

-Dan

Grills, Jeff wrote:

>I went through three months of harassing MS about this, providing them
>with a sample app that reproduced the problem, and still they didn't
>figure out what the problem was.  And here it is, the real reason, just
>like Dan said:
>
>	if (!GetThreadContext(GetCurrentThread(), &context))
>
>It sure would have been nice it this routine had failed.  Looking at the
>docs for GetThreadContext(), MS claims the following:
>
>	If you call GetThreadContext for the current thread, the
>function returns successfully; however, the context returned is not
>valid.
>
>Nice, an API with a silent failure.
>
>I really need to be able to capture call stacks at runtime from the
>running thread.  We have a warning system used when the game detects but
>recovers from an error (usually caused by faulty data coming from our
>own staff), and call stacks have proven vital to fixing those problems.
>Good thing I broke down and wrote my own routine to capture the call
>stack - it was only 25 lines of code, and much faster than StackWalk,
>too.
>
>j
>
>-----Original Message-----
>From: gam...@li...
>[mailto:gam...@li...] On Behalf Of
>Daniel Vogel
>Sent: Wednesday, February 09, 2005 12:50 PM
>To: gam...@li...
>Subject: RE: [GD-Windows] Call stack
>
>
>  
>
>>with the SP2 upgrade.  StackWalk won't walk the whole stack - 
>>it just gives up after returning 2 call stack frames.  I've 
>>    
>>
>
>I attached the code of our stack walking implementation (sorry for the
>formatting, notepad didn't like our usage of tabs). It works fine for
>walking the stack after a crash as we have easy access to all the
>information we need to feed StackWalk64.
>
>  
>
>>the stack.  I have plenty of cases in the engine where I 
>>capture a call stack for debugging later if something else 
>>    
>>
>
>IMO StackWalk64 is mostly useless for this case as you cannot call
>GetThreadContext on a running thread.
>
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/b
>ase/getthreadcontext.asp
>
>I assume you're doing this as that's exactly what we did with our proxy
>malloc and it broke with SP2 as well.
>
>-- Daniel, Epic Games Inc.
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
>_______________________________________________
>Gamedevlists-windows mailing list
>Gam...@li...
>https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>Archives:
>http://sourceforge.net/mailarchive/forum.php?forum_idU5
>
>
>  
>

RE: [GD-Windows] Call stack

[Jon W. <hp...@mi...>]

Replying to multiple replies here...


First: I ran the code I just posted on XP2 right before I posted
it. No OS update should make the EBP linkage any different -- that
would ruin the semantics of a compiled program. I take it from
your other comments that you really mean you're using the Microsoft
StackWalk function?


Second: I don't think CreateMiniDump is the right solution for the
initial problem the poster has, because he wanted a trace from each
and every call to his random routine, to compare the pattern in two
different run cases. Creating one minidump per random number
generated would sort-of crimp your interactivity :-)


Third: If you can't get the walking list to work, you can also scan
each aligned pointer word on the stack and see whether it points
at a return address. To do that, you first take the address and
compare to the executable image range of all loaded modules; if
it's in one of those, you can call a function like this:

You may get some false positives if you have sparse stack usage,
like declaring a char path[1024] in the middle of your stack
frame.


// Value is a pointer into what's known to be a code segment.
// Return TRUE if value would be the return address put on
// the stack by a function/method call.
bool
AddressRange::isReturnAddress( ptrdiff_t value )
{
  unsigned char const * ptr = (unsigned char const *)value;
  return (ptr[-5] == 0xe8) ||                 //  CALL xxxxx
    (ptr[-6] == 0xFF && ptr[-5] == 0x15) ||   //  CALL DWORD PTR xxxxx
    (ptr[0] == 0x83 && ptr[1] == 0xc4);       //  ADD ESP, imm8
}


Cheers,

            / h+

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Grills, Jeff
Sent: Wednesday, February 09, 2005 9:48 AM
To: gam...@li...
Subject: RE: [GD-Windows] Call stack


I have very similar code for walking the stack.  My code works on many
versions of windows, but it has stopped working as of Windows XP SP2.  I
even did a test on a machine where my test program worked, I upgraded to
SP2, and the test program stopped working, so I know it had something to do
with the SP2 upgrade.  StackWalk won't walk the whole stack - it just gives
up after returning 2 call stack frames.  I've ended up having to rewrite
StackWalk myself (which isn't very hard, if you disable the "Frame pointer
omission" optimization, since you can use the EBP register to walk up the
stack).  I've complained to Microsoft about this, but they haven't been very
quick to try and fix it.  Anyone else run into the same problem on XP SP2?
If it's just me, then I'll start comparing my code against other
implementations (like the one below) to see what I may doing wrong.  If it's
not just me, I'd be happy to share my stack walking code so that others can
work around the issue..

One thing I do differently than most other implementations I've seen is that
I don't do any symbol lookup while walking the stack.  I have plenty of
cases in the engine where I capture a call stack for debugging later if
something else goes wrong, and the symbol lookup may not be necessary.  For
instance, our memory manager can grab a stack for every allocation, and at
application exit time we can report the call stack for any memory leaks.
Typically all allocations are properly freed, so looking up the symbols when
capturing the call stack during an allocation is unnecessary and also
seriously impacts performance.  In the rare case of a memory leak (most
often discovered in new code that hasn't been submitted), very few addresses
need to be translated into symbols.

Jeff Grills
Senior Technical Director, Austin Studio
Sony Online Entertainment
-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of Simon
O'Connor
Sent: Wednesday, February 09, 2005 7:58 AM
To: gam...@li...
Subject: Re: [GD-Windows] Call stack



I wrote some code a while back that sounds like what you're after - or at
least should point you in the right direction:
http://www.sc3d.com/thought/snippets/debugging/GetFunctionCaller/
NB: It's not quite what I'd class as "production" quality - it was written
for debugging purposes only :o)
Cheers,

Simon O'Connor
Programmer @ Reflections Interactive
& Microsoft DirectX MVP

Re: [GD-Windows] Call stack

[brian s. <bri...@gm...>]

On Wed, 9 Feb 2005 13:49:44 -0500, Daniel Vogel
<Dan...@ep...> wrote:
> > the stack.  I have plenty of cases in the engine where I
> > capture a call stack for debugging later if something else
> 
> IMO StackWalk64 is mostly useless for this case as you cannot call
> GetThreadContext on a running thread.
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/b
> ase/getthreadcontext.asp
> 
> I assume you're doing this as that's exactly what we did with our proxy
> malloc and it broke with SP2 as well.

When I wrote my callstack walker for my malloc routine, I took the
docs at their word and assumed that calling GetThreadContext from my
current thread wouldn't work.  So I just filled in the relevant bits
of the STACKFRAME structure myself before calling StackWalk.

I haven't tested this code with SP2 yet though.  The best I can
promise is that it *might* not fall over :).

--brian

---- begin code -----

// This function exists because EIP cannot be read directly.
// What this function does is read the return address off the top of
// the stack into EAX, so that the caller can get a valid EIP value in
// their call frame.
__declspec(naked) void LoadCallerEipIntoEax(void)
{
   __asm {
       mov eax, [esp]
       ret
   }
}

   // Init the stack frame with relevant bits of thread context.  We
   // don't call GetThreadContext as it claims to not work for a
   // running thread
   STACKFRAME stackFrame;
   ZeroMemory(&stackFrame, sizeof(stackFrame));

   __asm {
       call LoadCallerEipIntoEax
       mov stackFrame.AddrPC.Offset,    eax
       mov stackFrame.AddrStack.Offset, esp
       mov stackFrame.AddrFrame.Offset, ebp
   };
   stackFrame.AddrPC.Mode    = AddrModeFlat;
   stackFrame.AddrStack.Mode = AddrModeFlat;
   stackFrame.AddrFrame.Mode = AddrModeFlat;

---- end code -----

--brian

RE: [GD-Windows] Call stack

[Mat N. \(BUNGIE\) <mat...@mi...>]

__try
{
	RaiseException(0,0,0,0);
}
__except(some_function(GetExceptionCode(), GetExceptionInformation())
{
}

GetExceptionInformation() will return a pointer that you can get the
current thread CONTEXT from.

MSN
-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Grills, Jeff
Sent: Wednesday, February 09, 2005 11:11 AM
To: gam...@li...
Subject: RE: [GD-Windows] Call stack


I went through three months of harassing MS about this, providing them
with a sample app that reproduced the problem, and still they didn't
figure out what the problem was.  And here it is, the real reason, just
like Dan said:

	if (!GetThreadContext(GetCurrentThread(), &context))

It sure would have been nice it this routine had failed.  Looking at the
docs for GetThreadContext(), MS claims the following:

	If you call GetThreadContext for the current thread, the
function returns successfully; however, the context returned is not
valid.

Nice, an API with a silent failure.

I really need to be able to capture call stacks at runtime from the
running thread.  We have a warning system used when the game detects but
recovers from an error (usually caused by faulty data coming from our
own staff), and call stacks have proven vital to fixing those problems.
Good thing I broke down and wrote my own routine to capture the call
stack - it was only 25 lines of code, and much faster than StackWalk,
too.

j

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Daniel Vogel
Sent: Wednesday, February 09, 2005 12:50 PM
To: gam...@li...
Subject: RE: [GD-Windows] Call stack


> with the SP2 upgrade.  StackWalk won't walk the whole stack -=20
> it just gives up after returning 2 call stack frames.  I've=20

I attached the code of our stack walking implementation (sorry for the
formatting, notepad didn't like our usage of tabs). It works fine for
walking the stack after a crash as we have easy access to all the
information we need to feed StackWalk64.

> the stack.  I have plenty of cases in the engine where I=20
> capture a call stack for debugging later if something else=20

IMO StackWalk64 is mostly useless for this case as you cannot call
GetThreadContext on a running thread.

http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/debug/=
b
ase/getthreadcontext.asp

I assume you're doing this as that's exactly what we did with our proxy
malloc and it broke with SP2 as well.

-- Daniel, Epic Games Inc.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU5

RE: [GD-Windows] Call stack

[Grills, J. <jg...@so...>]

I went through three months of harassing MS about this, providing them
with a sample app that reproduced the problem, and still they didn't
figure out what the problem was.  And here it is, the real reason, just
like Dan said:

	if (!GetThreadContext(GetCurrentThread(), &context))

It sure would have been nice it this routine had failed.  Looking at the
docs for GetThreadContext(), MS claims the following:

	If you call GetThreadContext for the current thread, the
function returns successfully; however, the context returned is not
valid.

Nice, an API with a silent failure.

I really need to be able to capture call stacks at runtime from the
running thread.  We have a warning system used when the game detects but
recovers from an error (usually caused by faulty data coming from our
own staff), and call stacks have proven vital to fixing those problems.
Good thing I broke down and wrote my own routine to capture the call
stack - it was only 25 lines of code, and much faster than StackWalk,
too.

j

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Daniel Vogel
Sent: Wednesday, February 09, 2005 12:50 PM
To: gam...@li...
Subject: RE: [GD-Windows] Call stack


> with the SP2 upgrade.  StackWalk won't walk the whole stack -=20
> it just gives up after returning 2 call stack frames.  I've=20

I attached the code of our stack walking implementation (sorry for the
formatting, notepad didn't like our usage of tabs). It works fine for
walking the stack after a crash as we have easy access to all the
information we need to feed StackWalk64.

> the stack.  I have plenty of cases in the engine where I=20
> capture a call stack for debugging later if something else=20

IMO StackWalk64 is mostly useless for this case as you cannot call
GetThreadContext on a running thread.

http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/debug/=
b
ase/getthreadcontext.asp

I assume you're doing this as that's exactly what we did with our proxy
malloc and it broke with SP2 as well.

-- Daniel, Epic Games Inc.

RE: [GD-Windows] Call stack

[Daniel V. <Dan...@ep...>]

> with the SP2 upgrade.  StackWalk won't walk the whole stack -=20
> it just gives up after returning 2 call stack frames.  I've=20

I attached the code of our stack walking implementation (sorry for the
formatting, notepad didn't like our usage of tabs). It works fine for
walking the stack after a crash as we have easy access to all the
information we need to feed StackWalk64.

> the stack.  I have plenty of cases in the engine where I=20
> capture a call stack for debugging later if something else=20

IMO StackWalk64 is mostly useless for this case as you cannot call
GetThreadContext on a running thread.

http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/debug/=
b
ase/getthreadcontext.asp

I assume you're doing this as that's exactly what we did with our proxy
malloc and it broke with SP2 as well.

-- Daniel, Epic Games Inc.