Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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: <40FF80E7.5030809@expertron.co.za> Date: Thu, 22 Jul 2004 10:55:03 +0200 From: Justin Schoeman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: henning AT hhschmidt DOT de CC: cygwin AT cygwin DOT com Subject: Re: 1.5.10: problems relocating structures with function pointers References: <40FF7D2D DOT 5020101 AT gmx DOT net> In-Reply-To: <40FF7D2D.5020101@gmx.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mail.innovationhub.co.za X-Spam-Level: X-Spam-Status: No, hits=-82.8 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.63 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] * -100 USER_IN_WHITELIST From: address is in the user's white-list * 22 AWL AWL: Auto-whitelist adjustment X-IsSubscribed: yes Note-from-DJ: This may be spam As was explained in the previous post, the structure must be defined as 'extern' when referenced from test.c - a stupid mistake from my side. Why I thought it was a bug was that the code worked perfectly on the same compiler version under Linux and Solaris, but failed under Cygwin. The fact that it works on Linux, means that the 'bug' (the compiler linking against an extern symbol, even when declared localy) exists on almost all current versions of gcc / binutils... Could be an interesting bug to fix, but should not _really_ be a problem, as it is unlikely to be triggered in good code. Thanks, -justin H. Henning Schmidt wrote: >>I have discovered what may be a bug in the linker/relocater in cygwin >>(or, more likely, I am doing something stupid again). > > >>When I use a structure containing function pointers, and this >>structure is placed in an archive, then the function pointer becomes >>NULL. As an example, compile the attached files as follows: >> >>gcc -O2 -Wall -c inc.c >>ar rsvc inc.a inc.c >>gcc -O2 -Wall -o test test.c inc.a >> >>Executing test.exe prints 0x0 (the address of the function cointained >>in the structure), and subsequently segfaults. >> >>Relinking with >> >>gcc -O2 -Wall -o test test.c inc.o >> >>produces a binary that works correctly. >> >>It seems that once the object file is archived, the dynamic loader >>losses the capability of correctly assigning the function addresses? >> >>Any help would be greatly appreciated. > > > You are constructing two instances of type . One as global > static member of the module , and another instance in module > . The one in module gets initalized (i.e. func pointer is > set to address of local func ), the other one remains > uninitialized. Both of these instances of type are named > ... which is certainly a little confusing. > AFAIK, the code in main() should always and only reference the local > instance (the uninitialized one from module ), which would result > in an output of either 0x0 (or any other random number, really ... this > is just reading unitialized memory). > > To my understanding, the fact that your second linker invocation (direct > linking, no static archive involved) does use the static (and thus > presumably invisible) instance of from the module does > indicate a (completely different) bug in the linker ... > > -- > 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/ > -- 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/