* problems with linker
@ 1997-09-05 6:32 Andreas Jellinghaus
1997-09-07 0:10 ` Fergus Henderson
0 siblings, 1 reply; 3+ messages in thread
From: Andreas Jellinghaus @ 1997-09-05 6:32 UTC (permalink / raw)
To: gnu-win32
i have big problems with the dynamic linker :
there is a function Pof_Create that creates a linked list of type void*.
we have a static table mOblist with entry Create, to typecast this to
the right type, so we don't need to typecast with every function call.
The items in this list should have the addresses of the Pof_ functions.
when i link my program (calling the functions in this struct) static with the
library (the struct and all functions are in this library), everything
works ok. but if i create a simple or a relocable dll and link with the dll,
the struct has bad values and i get segmentation faults.
i don't know, what i can try next ...
any hints ?
thanks for your help.
andreas
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: problems with linker
1997-09-05 6:32 problems with linker Andreas Jellinghaus
@ 1997-09-07 0:10 ` Fergus Henderson
0 siblings, 0 replies; 3+ messages in thread
From: Fergus Henderson @ 1997-09-07 0:10 UTC (permalink / raw)
To: gnu-win32; +Cc: aj
Andreas Jellinghaus <jelling@iitb.fhg.de> writes:
>i have big problems with the dynamic linker :
>there is a function Pof_Create that creates a linked list of type void*.
>we have a static table mOblist with entry Create, to typecast this to
>the right type, so we don't need to typecast with every function call.
>The items in this list should have the addresses of the Pof_ functions.
>
>when i link my program (calling the functions in this struct) static with the
>library (the struct and all functions are in this library), everything
>works ok. but if i create a simple or a relocable dll and link with the dll,
>the struct has bad values and i get segmentation faults.
If you're accessing a DLL's global or static variables from outside
the DLL, then some additional work is needed. See
< http://www.cs.mu.oz.au/~fjh/gnu-win32/how-to-build-dlls.html >.
P.S. For anyone already using the Makefile.DLLs from that WWW page,
I recently updated that with a patch from Sergey, so the main program
no longer needs to explicitly set the DLL's impure_ptr.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh > | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".
^ permalink raw reply [flat|nested] 3+ messages in thread
* Problems with linker
@ 2000-08-17 18:57 Graeme Campbell
0 siblings, 0 replies; 3+ messages in thread
From: Graeme Campbell @ 2000-08-17 18:57 UTC (permalink / raw)
To: cygwin
I am a newbie to using cygwin and GCC, but have found generally the tools
to be excellent.
I have recently however found some problems with the linker producing
corrupt images, and crashing. I am using GCC-2.92.2-1, which worked fine
with the linker created from binutils-19990818. We produce an image used
in an embedded system by linking together a number of modules in a
incremental link using the -r option, which are then linked to the final image.
The target hardware is PPC, using ELF and DWARF2 debugging. The
problem with the original linker was that it tended to stack dump if it could
not resolve some symbols in the final link.
The linker in the next two releases of binutils (binutils-20000625 and binutils-
20000722-1 ) produced corrupt images, but would tell us which symbols
were unresolved.
I investigated the corruption using GDB on the linker, and found two
separate problems in the routine gldelf32ppc_place_orphan in the file
eelf32ppc.c, which is automatically generated from the template file
elf32.em.
The first problem is that special data sections we use ( created with the
__attribute__ ((section ("special"))) keywords, were being set to zero size in
the incremental link.
I fixed that by adding an extra test for a relocatable link in the following line
if (place->stmt == NULL || link_info.relocateable)
{
/* Put the new statement list right at the head. */
*add.tail = place->os->header.next;
place->os->header.next = add.head;
}
else
{
/* Put it after the last orphan statement we added. */
*add.tail = *place->stmt;
*place->stmt = add.head;
}
Then I found that the .sbss section variables were also being set to zero
size. This I fixed by adding an extra test for a relocateable link and putting
both .sbss and .bss into the .data section. Note .bss was already being put
into the .data section
if (s->flags & SEC_EXCLUDE)
return false;
else if ((s->flags & SEC_ALLOC) == 0)
place = NULL;
else if ((s->flags & SEC_LOAD) != 0
&& strncmp (secname, ".note", 4) == 0
&& HAVE_SECTION (hold_interp, ".interp"))
place = &hold_interp;
else if ((s->flags & SEC_HAS_CONTENTS) == 0
&& link_info.relocateable
&& HAVE_SECTION (hold_data, ".data"))
place = &hold_data;
else if ((s->flags & SEC_HAS_CONTENTS) == 0
&& HAVE_SECTION (hold_bss, ".bss"))
place = &hold_bss;
My changes work in our environment, but may well work for completely the
wrong reasons, or not be the correct way to fix the problem.
One further problem I also investigated was a stack dump due to a divide by
zero error. This was found to be due to the linker trying to determine the line
number of an unresolved symbol in the link and dividing by zero. This
occurs in the file bfd/dwarf2.c routine decode_line_info, where it divides by
lh.line_range.
Graeme Campbell
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-08-17 18:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-09-05 6:32 problems with linker Andreas Jellinghaus
1997-09-07 0:10 ` Fergus Henderson
2000-08-17 18:57 Problems " Graeme Campbell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).