Re: gettext patches for cygwin #1: rdata

[Bruno Haible]

Charles Wilson wrote:
> I had no difficulty with long_options[] that contained 
> only constants.  I was being preventative, rather than curative, there. 
>   I figured that it was better to have all the application code "look" 
> the same, so that IF somebody later added a flag that took a value, they 
> wouldn't have to remember to also change 'const' to 'FUNKY_CONST_MACRO'.

You're right. It's better to make a change systematically, rather than only
at isolated places.

> You keep going on about 'valid ANSI C code'.  I'm wondering what that 
> has to do with tea in China?  It may be valid, but as coded in 0.14.5, 
> on win32, building shared, *it does not work*. It compiles, links, but 
> fails to run. It doesn't matter if it's valid C code; it's an 
> acknowledged deficiency of the Win32 platform and good luck getting Bill 
> to fix it.  We're stuck with workarounds of various kinds.

True. And I try to choose the workarounds that require the least knowledge
of the code or are the most automatic.

> This is a **slightly** different issue than the typical 'access stuff 
> from a DLL'.  This is 'access stuff from a DLL, using a pointer that is 
> declared const [even if only indirectly declared const via enclosing 
> struct const-ness], and so is placed in non-writable memory and can't be 
> fixed up after process load'[*].  That's why it was a separate patch 
> from my #4.
> 
> [*] This affects "regular" pointer variables if they are const and at 
> file scope in the caller app (function scope vars are not placed in the 
> .rdata section, even if const).  The problem not limited to 
> long_option-type situations.
> 
> It's the 'const-ness' of the pointer variable that must hold the 
> relocated address of the imported data that causes the problem, not 
> whether the data is imported via canonical declspec(__dll[ex|im]port), 
> or via auto-import.

It is this kind of low-level reasoning - and the amount of time it takes
to understand it - that takes away brain cycles from the programmer. This
knowledge is essential for the person who will implement the workaround in
gcc. It's good that you wrote it down once, for reference. But for an
average application programmer, this excursion to assembly-language and
compiler internals drags his attention away from the actual application's
purpose. That's what I mean by "valid ANSI C code": everything below this
level is the business of the system implementor, not of the application
programmer.

> > - and
> > use g++ instead of gcc - this causes the initialization of the
> > long_options[] array to be performed at runtime instead of at compile-time.
> 
> With regards to the long_options stuff, DLL_VARIABLE magic isn't helping 
> you in this particular case, even when applied to the target variable 
> (line_comment) imported from the DLL.  Really, you're relying completely 
> on the g++/gcc replacement to solve that issue (because compiling with 
> g++ would "solve" the problem even if line_comment were not 
> DLL_VARIABLE; auto-import would activate, and 'line_comment' itself is 
> not a "complex" variable).  Since g++ delays initialization, it knows to 
> "ignore" the 'const' on the long_options[] declaration and NOT put the 
> structure into .rdata.

Are you sure this would work without the DLL_VARIABLE declaration? I think
that without the DLL_VARIABLE,
  - the compiler (cc1 or cc1plus) would treat the reference optimistically
    like a reference to an address in the same executable,
  - the assembler would likewise straightforwardly transform it to an
    address in a different translation unit,
  - and all the burden would remain on the linker:
      - changing the reference of the address to a NULL,
      - changing the section of the array that contains it from .rdata
        to .data,
      - adding the __constructor__ function that replaces the NULL with
        the runtime value of the reference.

Are you sure the linker can do this? Are you willing to write that piece of
linker code? I think it's easier to do it in cc1.

Bruno