This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 64bit: cygstdc++-6.dll


On 2013-04-15 11:48, Corinna Vinschen wrote:
> On Apr 14 13:28, Corinna Vinschen wrote:
>> On Apr 14 13:09, Kai Tietz wrote:
>>> No, IMHO it is a flaw to make const-data and text sections in
>>> pe-coff-image by default writable without good need.  v1 and v2
>>> pseudo-relocation are capable to handle read-only sections.
>>
>> Sure.  I'd say the same goes for Cygwin images.  .text is R/O anyway, so
>> that only leaves the .rdata content moved to .data when auto-image is
>> enabled.  Given that this seems to be old behaviour, based on an old
>> assumption, it seems we could just get rid of the .xa ldscript to fix
>> this issue in future.
>>
>> Does anybody volunteer to have a look into this and send a patch upstream
>> to binutils?
> 
> For testing, I created a simple testcase:
> 
>   $ cat <<EOF > x.c
>   #include <stdio.h>
>   extern int optind;
>   int main () { printf ("optind: %d,%p\n", optind, &optind);
>   EOF
> 
> On 32 bit:
> 
>   $ gcc -o x x.c
>   $ objdump -h x
>   [...]
>   0 .text         00000748  00401000  00401000  00000400  2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
>   1 .data         00000098  00402000  00402000  00000c00  2**5
>                   CONTENTS, ALLOC, LOAD, DATA
>   2 .rdata        00000024  00403000  00403000  00000e00  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   3 .eh_frame     00000004  00404000  00404000  00001000  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>   4 .bss          00000110  00405000  00405000  00000000  2**5
>                   ALLOC
>   5 .idata        000001e0  00406000  00406000  00001200  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>   [...]
>   $ nm x | grep optind
>   0040117f T __fu0__optind
>   00401187 T __fu1__optind
>   004060a0 I __imp__optind
>   004060a0 I __imp__optind
>   00406140 I __nm__optind
> 
> So on 32 bit we have two symbols in .text and 3 symbols in .idata.
> On 64 bit:
> 
>   $ gcc -o x x.c
>   $ objdump -h x
>   [...]
>   0 .text         00000760  0000000100401000  0000000100401000  00000400  2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
>   1 .data         00000048  0000000100402000  0000000100402000  00000c00  2**5
>                   CONTENTS, ALLOC, LOAD, DATA
>   2 .rdata        00000308  0000000100403000  0000000100403000  00000e00  2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   3 .pdata        000000e4  0000000100404000  0000000100404000  00001200  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   4 .xdata        00000088  0000000100405000  0000000100405000  00001400  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   5 .bss          000001c0  0000000100406000  0000000100406000  00000000  2**5
>                   ALLOC
>   6 .idata        0000025c  0000000100407000  0000000100407000  00001600  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>   $ nm x  | grep optind
>   0000000100403050 r .rdata$.refptr.optind
>   0000000100403050 R .refptr.optind
>   0000000100403050 R __fu0_optind
>   0000000100407104 I __imp_optind
>   0000000100407104 I __imp_optind
>   00000001004071bc I __nm_optind
>     
> So on 64 bit we have three symbols in .rdata and 3 in .idata.  
> 
> On 32 bit, the .xa script is used, but has no influence, apparently.
> On 64 bit, the .x script is used, even with --enable-auto-import.
> Both versions work as expected:
> 
>   $ ./x
>   optind: 1,0x611821e4
> 
>   $ ./x
>   optind: 1,0x1801c37bc
> 
> To me this means, we should not use the .xa file on 32 bit either.
> It moves all .rdata data to the .data section for no good reason,
> thus adding unnecessary pressure to the pagefile.
> 
> Does that make sense or did I miss something?
> 
> 
> Corinna
> 

IIRC it was more problematic with complex data structures and needing
more than one relocation for a "single lookup". Like importing a const
that is used as offset in an imported const array, or something like
that. Or, I'm completely off base and that was a totally different
problem, sorry for the noise in that case.

Cheers,
Peter


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]