please don't apply RPC Merge D_PL1

[Greg Turner]

On Tuesday 15 October 2002 10:53 am, Ove Kaaven wrote:
> On Mon, 14 Oct 2002, Greg Turner wrote:
> > well, that sounds about right, but how to detect such a thing...?
> > I guess I need to learn how to create 'on change some ram'
> > breakpoints,
>
> That's called "watchpoints". In gdb, you can set such a watchpoint with:
> watch *(int*)0xaddress
>
> > not to mention track down these datastructures
> > in memory (or perhaps learn how to get debug symbols for
> > w32-native-compiled stuff generated).
>
> Well you can just use the pointer given to NdrClientCall2, right?

yes, but by then it's too late; besides, by the time we're in NdrClientCall2,
I no longer trust anything I see.  To pursue this, I need to snag it
as early as possible.  I was able to produce a .pdb file using the
compiler.  Winedbg loads it but still no dice.  I'd almost rather just
get to the raw data than worry about debug symbols in this case.
I can put some magic numbers in there and grep the various
allocated memory places, to generate some nice re-usable 
offsets.  Anyhow, if it's a calling convention problem as discussed
below, then presumably I would find no memory corruption, so I will
look into that first.

>
> > Serveral differences worth noting:
> >
> > o Many more dlls loaded in the winelib version (why?)
>
> Perhaps you have lots of unneeded import statements in your Winelib app's
> .spec file.

that sounds right.  winemaker seemed to generate a lot of
superflous deps (and failed to generate the rpcrt4 one).

> > My theories:
> >
> > o it's the try/except macros; they're causing stack corruption or
> > something (they occur right before the NdrClientCall2)
> > o it's MIDL_user_allocate somehow (nah)
> > o it's a problem with dll loading (lets hope not)
>
> o it's a calling convention problem (stdcall/cdecl, argument count, return
> value). This theory is substantiated by the difference in the pFormat
> argument. Perhaps gcc wants to return the CLIENT_CALL_RETURN structure in
> a way that isn't compatible with what Microsoft compilers expect (wants
> stack space reserved for it by the caller or something?)... I think we've
> had issues with gcc and returning structures before. If this is it, rpcrt4
> probably need to return it as just LONG_PTR in the code, not
> CLIENT_CALL_RETURN?

I like this theory, it has recently occured to me too.  I will try compiling the 
sample using stdcall and see if that has an effect, after work.  Also,
in the winelib version, I changed main() to stdcall from cdecl (!) which
I took to mean that winelib framework didn't want that calling convention.

As for fixing it... this may be a bit beyond me; but I'll look into what
you reccomend.  If gcc and msvc use incompatible cdecl conventions
then that's a pretty serious problem, right, not just for rpcrt4?  Looks
like to fix I will need to read some machine code.

If there's a fundamental problem here, I guess this would mean 
we'd have to install gcc<->msvc cdecl thunks somewhere to
properly fix the problem?  Well, perhaps not, just thinking out loud.
I'll look into this tonight; I bet you are on to something here.

-- 
gmt

"It has been well said that really up-to-date liberals
do not care what people do, as long as it is compulsory."

-George F. Will