httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Costello" <timcoste...@ozemail.com.au>
Subject RE: [PROPOSED] linkage spec names, final binding vote
Date Thu, 01 Jun 2000 12:38:49 GMT
On Tuesday, 30 May 2000, William A. Rowe, Jr. wrote:
> > I think it's better to just have code that is code (which is 
> > compiled), and
> > another file that says what can be accessed from outside 
> > (which is used by 
> > the linker). 
> > 
> > > 2) `simplest method that works` is, as you point out for the
> > >    case of data, simply incorrect. 
> > 
> > Sorry, I was talking about the export directives only, not importing. 
>  
> Wait... you are willing to argue we need the macros for importing
> functions and data?  And that they should serve no purpose when

No, just data - meaning global variables. Of which there are hopefully few. 

I think what we're disagreeing on is the value of eliminating the thunks 
you get in code when you only link using an import library, and don't 
specify __declspec(dllimport). One unconditional jump per function call 
doesn't seem (to me) to be worth putting additional compiler directives 
into the code (even if they're done using macros). 

The fact that it's only one unconditional jump is illustrated by the
assembly you included back in early April. fn_a used only the import
library's thunk (symbol _fn_a below), where fn_c was __declspec(dllimport).

> 17:       t1 = fn_a(1);
> 00401035   push        1
> 00401037   call        _fn_a(0x004010a0)
> 0040103C   add         esp,4
> 0040103F   mov         dword ptr [t1],eax
...
> 19:       t3 = fn_c(3);
> 0040104F   push        3
> 00401051   call        dword ptr [__imp__fn_c(0x0041629c)]
> 00401057   add         esp,4
> 0040105A   mov         dword ptr [t3],eax
...
> _fn_a:
> 004010A0   jmp         dword ptr [__imp__fn_a(0x00416294)]
...
> __imp__fn_a:
> 00416298   1000100A
> __imp__fn_c:
> 0041629C   1000100F

Please understand that this is a value judgement and something that we could
argue about forever - I'm not debating the issue now, just trying to explain
my perspective. 

What started my rant was me trying (just for fun) to compile Apache on Win32
as a monolithic executable. Before anyone complains that this would be a
retrograde step, the things involved are the same sorts of things that are 
involved if we want to move functions (from a packaging perspective) from 
the core to APR or vice versa. 

A more dramatic move would be to split APR's binary package on windows into 
multiple libraries, one for network i/o, one for file i/o, etc. At the 
moment, that's just not possible - to make it possible, there'd be a 
significant effort involved in getting the declspecs correct for callers 
and callees. If the current model were extended - a macro to indicate if 
we're inside, and macros specific to the package that either dllimport or 
dllexport, then we'd end up with a plethora of macros that did similar 
things (and probably with similar names). This is just an example - more 
probable is moving single functions from core -> apr and vice versa. 

In summary - let linkage issues be dealt with by the linker, not by compiler
directives. 

and from another email:
> > I think (on Win32 at least) we should '#define 
> > AP?_EXPORT(type) type' and use DEF files for symbol 
> > exporting.
> 
> Sorry, I answered the last half of your question in my 
> original reply, but didn't notice the other aspect.

wow - I'm impressed. I didn't even realise I was talking about calling
conventions :-)

> If anyone wants APR (__cdecl) or apache (__stdcall)
> toggled, speak up.  I was considering some benchmarks of
> both __cdecl, and both __stdcall, but I'm not there yet.

My only opinion on this one is that we should be consistent. I didn't
realise we had different default conventions for the core and for APR. Is
there a reason?

Tim

Mime
View raw message