problems with linker

problems with linker

[Andreas Jellinghaus]

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".

Re: problems with linker

[Fergus Henderson]

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".

Problems with linker

[Graeme Campbell]

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