This is the mail archive of the
mailing list for the Cygwin project.
Re: 64bit: cygstdc++-6.dll
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Sun, 14 Apr 2013 13:28:30 +0200
- Subject: Re: 64bit: cygstdc++-6.dll
- References: <20130411101639 dot GB12461 at calimero dot vinschen dot de> <20130411133759 dot GC18333 at calimero dot vinschen dot de> <20130412155750 dot GG11358 at calimero dot vinschen dot de> <51686F09 dot 4050009 at gmail dot com> <20130413100751 dot GI11358 at calimero dot vinschen dot de> <5169BB2E dot 80807 at gmail dot com> <20130414082512 dot GL11358 at calimero dot vinschen dot de> <CAEwic4aGerGAdmN2xupYFNuvLVfab2MofJg=m5gp-JsFgh0NGg at mail dot gmail dot com> <20130414101859 dot GM11358 at calimero dot vinschen dot de> <CAEwic4b3OKXpb+yQzomLFAp55QhGEfSb+ibhs7eoEN3kqKHTtw at mail dot gmail dot com>
- Reply-to: cygwin-apps at cygwin dot com
On Apr 14 13:09, Kai Tietz wrote:
> 2013/4/14 Corinna Vinschen wrote:
> > On Apr 14 11:05, Kai Tietz wrote:
> >> Also the argumentation about none-autoimporting enabled links puzzles
> >> me, too. If no auto-import happens there is no need to do
> >> page-access-remappings done by gcc or ld. As nobody writes actual to
> >> these pages from POV of pe-loader. Cygwin might want to optimize the
> >> amount of pages needing remapping by sorting pseudo-GOT-entries in
> >> image together, but that is for sure a different story as to move
> >> things from rdata into data, or making code-section writable.
> > IIUC the 32 bit stuff is not organized in pseudo-GOT entries, so this
> > might be a bit tricky to accomplish for 32 bit, unless the affected
> > auto-import entries are subsumed under the .rdata_runtime_pseudo_reloc
> > section.
> > As far as the pseudo-GOT entries in the 64 bit code are concerned,
> > aren't they in the .rdata_runtime_pseudo_reloc section anyway?
> Yes, they are by default in .rdata section.
> > We just have to give up the .xa ldscript method.
> IMHO yes, I see no good reason to move them into data, as after
> psuedo-relocation they are const, and have to be const.
> >> If cygwin needs that behavior in gcc (and binutils), then do this
> >> please in cygwin-specific way there. It is in general a flaw to have
> >> this also for native windows targets enabled.
> > I don't understand what you mean here. What exactly is a flaw to have
> > for native windows? Auto-import?
> 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
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com