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: <40FF7D2D.5020101@gmx.net>
Date: Thu, 22 Jul 2004 10:39:09 +0200
From: "H. Henning Schmidt" <hhschmidt AT gmx DOT net>
Reply-To: henning AT hhschmidt DOT de
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: 1.5.10: problems relocating structures with function pointers
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


> 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 <struct js>. One as global
static member of the module <inc>, and another instance in module
<test>. The one in module <inc> gets initalized (i.e. func pointer is
set to address of local func <junk>), the other one remains
uninitialized. Both of these instances of type <struct js> are named
<jsi> ... which is certainly a little confusing.
AFAIK, the code in main() should always and only reference the local
instance (the uninitialized one from module <test>), 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 <struct js> from the <inc> 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/