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 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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat


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