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
