delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2004/09/22/17:02:33

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <4151E85A.5020305@cwilson.fastmail.fm>
Date: Wed, 22 Sep 2004 17:02:18 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 MultiZilla/1.6.4.0b
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: cygwin, libtool, dlpreopen, and .rdata
References: <41511C3F DOT 7080003 AT cwilson DOT fastmail DOT fm> <Pine DOT CYG DOT 4 DOT 58 DOT 0409221012570 DOT 2736 AT fordpc DOT vss DOT fsi DOT com> <cisbll$m8u$1 AT sea DOT gmane DOT org>
In-Reply-To: <cisbll$m8u$1@sea.gmane.org>

Shankar Unni wrote:

> Brian Ford wrote:
> 
>> Yes, I see.  I hope Danny Smith might weigh in here?
>>
>> http://sources.redhat.com/ml/binutils/2004-02/msg00003.html
> 
> 
> I would argue that this is gcc's responsibility. If a const structure 
> variable contains *any* code or data addresses, it's not safe to put it 
> in .rdata (or .rodata, whatever the platform calls it), because of 
> relocation issues.
> 
> So rather than detect a "DLL import", I'd say *any* function addresses 

Actually, *function* addresses are fine; they don't get relocated (at 
least, not by the runtime-pseudo-reloc gobbledygook).  It's only the 
addresses of DATA items exported by DLLs that get relocated in this way.

AND, they get relocated IF AND ONLY IF you are linking to a DLL.  If you 
link to a static library, no runtime relocation is necessary because the 
linker resolves all of the addresses in question at link time.  And if 
(really the same issue as a static lib) the addresses in question come 
from a standalone .o (e.g. an extern data item in your own app, not one 
supplied by a library at all) then why shouldn't it be const -- and put 
in .rdata?

But how is gcc supposed to know that you're going to link to a DLL? 
(The same question applies to creating the trampolines for DATA exports 
in the first place, and that took some seriously hairy code and over a 
year to get it right, and stabilized).

Yeah, you could play it safe and just say "In x86, any structure or 
variable that is initialized with the address of any variable (but not 
function), should go into .data, not .rdata" -- and lose the benefits of 
const==.rdata for those structures.  But that "punishes" many common 
cases in the interests of making a few rare cases work properly.

Sometimes the answer really is "Don't do that.": don't declare structs 
const if they contain addresses of data coming from an external library.

> in a const initializer should cause the variable to go into a regular 
> .data section, without any complicated decision-making by binutils.
> 
> (Note: this is not the same problem that Danny talks about in that 
> message - that usage was legitimate, and there was no attempt to have a 
> const initialized variable with a data address.)

Correct.

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019