Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com To: cygwin@cygwin.com From: Shankar Unni Subject: Re: cygwin, libtool, dlpreopen, and .rdata Date: Wed, 22 Sep 2004 10:09:48 -0700 Lines: 18 Message-ID: References: <41511C3F.7080003@cwilson.fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ppp-67-124-90-144.dsl.pltn13.pacbell.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.6.0.101 In-Reply-To: X-IsSubscribed: yes 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 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.) -- 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/