X-Spam-Check-By: sourceware.org
X-Authenticated-As:  none
Date: Thu, 19 Jul 2007 22:54:12 +0200
From: Hans Streibel <streibel DOT 2006 AT gmx DOT net>
To: cygwin AT cygwin DOT com
Subject: SOLUTION: Own Compiled Program Immediately Crashes on Startup
Message-ID: <20070719205412.GA7046@df8xq-l2.streibel.net>
References: <026a01c7c932$4cae0810$2e08a8c0 AT CAM DOT ARTIMI DOT COM> <20070718121556 DOT 83920 AT gmx DOT net> <026e01c7c936$bad581c0$2e08a8c0 AT CAM DOT ARTIMI DOT COM> <20070718133420 DOT 83920 AT gmx DOT net> <027901c7c941$c6e51e70$2e08a8c0 AT CAM DOT ARTIMI DOT COM> <20070718140257 DOT 83920 AT gmx DOT net> <027e01c7c947$31c0d310$2e08a8c0 AT CAM DOT ARTIMI DOT COM> <469E25B2 DOT 3A0A359A AT dessent DOT net> <20070718150917 DOT 83910 AT gmx DOT net> <469E31D4 DOT 4733053E AT dessent DOT net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C"
Content-Disposition: inline
In-Reply-To: <469E31D4.4733053E@dessent.net>
User-Agent: Mutt/1.5.11+cvs20060126
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
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

--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jul 18, 2007 at 08:29:24AM -0700, Brian Dessent wrote:
> The problem
> occurs when you have a data structure (typically a struct) declared
> const that contains any reference to a variable that is imported from
> another DLL.  A fuller explanation is
> <http://www.cygwin.com/ml/cygwin/2004-09/msg01101.html>.
> 
> As you can see from Chuck's message it's kind of a hairy situation in
> that there is no "real" fix for it other than undoing the optimization
> of placing these in a readonly section.  That can be accomplished by
> either using a modified linker script or by removing the 'const' from
> the declaration.  The former is a sort of brute force/last ditch
> approach which is useful if you have a very large code base with lots of
> modules and you can't or don't want to hunt down the offending structs. 
> I think the qt project had to take this approach:
> <http://www.cygwin.com/ml/cygwin/2004-10/msg01052.html>
> 
> I'm not convinced this is what's wrong in your case, but it fits the
> symptoms so it's worth ruling out.

Hello Brian,

that's it! Thanks a lot for your hint.

I was wrong with my assumption that it was only K&R C code.
Obviously someone is maintaining the code - and put "const" modifiers
into the code.

I followed that brute force method with the modified linker
script - and succeeded.

For all of you who might have the same problem in future, I
include that linker script in the attachment. Store it under:
	/lib/ldscripts/i386pe.x-no-rdata
And use these options for linking (use gcc!):
	-Wl,--script,/lib/ldscripts/i386pe.x-no-rdata


One big problem remains. Maybe I should better start a new thread for
this but maybe someone has a quick answer for me here...

Jove is an Emacs like editor. As such it uses the key sequence
CONTROL-X CONTROL-C (^X^C) for leaving the editor.
In Cygwin however ^C still sends the interrupt signal to the editor.
However the keystroke ^C should have been changed to not sending
that signal. On most platforms that works - but not in Cygwin.

I can't tell right now what mechanism Jove is using for handling
the terminal under Cygwin. There so many mechanisms:
"struct termio", "struct termios", "struct sgttyb".
Jove under Cygwin follows BSD POSIX.

Does anyone have an idea on how that interrupt signal can
be switched off for ^C? Jove's code seems to be ok here because
I already compiled that code on several platforms.
A bug in Cygwin? What should be used in Cygwin:
- struct termio
- struct termios
- struct sgttyb

Interesting to know:
I just installed "screen" and Jove's exit command (^X^C) is working
fine under screen. So what is different?

Hans

--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="i386pe.x-no-rdata"

/* specific linker script avoiding .rdata sections, for normal executables 
for a reference see 
http://www.cygwin.com/ml/cygwin/2004-09/msg01101.html
http://www.cygwin.com/ml/cygwin-apps/2004-09/msg00309.html
*/
OUTPUT_FORMAT(pei-i386)
SEARCH_DIR("/usr/i686-pc-cygwin/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/lib/w32api");
ENTRY(_mainCRTStartup)
SECTIONS
{
  .text  __image_base__ + __section_alignment__  :
  {
     *(.init)
    *(.text)
    *(SORT(.text$*))
    *(.glue_7t)
    *(.glue_7)
     ___CTOR_LIST__ = .; __CTOR_LIST__ = . ;
			LONG (-1);*(.ctors); *(.ctor); *(SORT(.ctors.*));  LONG (0);
     ___DTOR_LIST__ = .; __DTOR_LIST__ = . ;
			LONG (-1); *(.dtors); *(.dtor); *(SORT(.dtors.*));  LONG (0);
     *(.fini)
    /* ??? Why is .gcc_exc here?  */
     *(.gcc_exc)
    PROVIDE (etext = .);
    *(.gcc_except_table)
  }
  /* The Cygwin32 library uses a section to avoid copying certain data
     on fork.  This used to be named ".data".  The linker used
     to include this between __data_start__ and __data_end__, but that
     breaks building the cygwin32 dll.  Instead, we name the section
     ".data_cygwin_nocopy" and explictly include it after __data_end__. */
  .data BLOCK(__section_alignment__) :
  {
    __data_start__ = . ;
    *(.data)
    *(.data2)
    *(SORT(.data$*))
    *(.rdata)
    *(SORT(.rdata$*))
    *(.eh_frame)
    ___RUNTIME_PSEUDO_RELOC_LIST__ = .;
    __RUNTIME_PSEUDO_RELOC_LIST__ = .;
    *(.rdata_runtime_pseudo_reloc)
    ___RUNTIME_PSEUDO_RELOC_LIST_END__ = .;
    __RUNTIME_PSEUDO_RELOC_LIST_END__ = .;
    __data_end__ = . ;
    *(.data_cygwin_nocopy)
  }
  .rdata BLOCK(__section_alignment__) :
  {
  }
  .pdata BLOCK(__section_alignment__) :
  {
    *(.pdata)
  }
  .bss BLOCK(__section_alignment__) :
  {
    __bss_start__ = . ;
    *(.bss)
    *(COMMON)
    __bss_end__ = . ;
  }
  .edata BLOCK(__section_alignment__) :
  {
    *(.edata)
  }
  /DISCARD/ :
  {
    *(.debug$S)
    *(.debug$T)
    *(.debug$F)
    *(.drectve)
  }
  .idata BLOCK(__section_alignment__) :
  {
    /* This cannot currently be handled with grouped sections.
	See pe.em:sort_sections.  */
    SORT(*)(.idata$2)
    SORT(*)(.idata$3)
    /* These zeroes mark the end of the import list.  */
    LONG (0); LONG (0); LONG (0); LONG (0); LONG (0);
    SORT(*)(.idata$4)
    SORT(*)(.idata$5)
    SORT(*)(.idata$6)
    SORT(*)(.idata$7)
  }
  .CRT BLOCK(__section_alignment__) :
  {
    ___crt_xc_start__ = . ;
    *(SORT(.CRT$XC*))  /* C initialization */
    ___crt_xc_end__ = . ;
    ___crt_xi_start__ = . ;
    *(SORT(.CRT$XI*))  /* C++ initialization */
    ___crt_xi_end__ = . ;
    ___crt_xl_start__ = . ;
    *(SORT(.CRT$XL*))  /* TLS callbacks */
    /* ___crt_xl_end__ is defined in the TLS Directory support code */
    ___crt_xp_start__ = . ;
    *(SORT(.CRT$XP*))  /* Pre-termination */
    ___crt_xp_end__ = . ;
    ___crt_xt_start__ = . ;
    *(SORT(.CRT$XT*))  /* Termination */
    ___crt_xt_end__ = . ;
  }
  .tls BLOCK(__section_alignment__) :
  {
    ___tls_start__ = . ;
    *(.tls)
    *(.tls$)
    *(SORT(.tls$*))
    ___tls_end__ = . ;
  }
  .endjunk BLOCK(__section_alignment__) :
  {
    /* end is deprecated, don't use it */
    PROVIDE (end = .);
    PROVIDE ( _end = .);
     __end__ = .;
  }
  .rsrc BLOCK(__section_alignment__) :
  {
    *(.rsrc)
    *(SORT(.rsrc$*))
  }
  .reloc BLOCK(__section_alignment__) :
  {
    *(.reloc)
  }
  .stab BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.stab)
  }
  .stabstr BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.stabstr)
  }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section.  Unlike other targets that fake this by putting the
     section VMA at 0, the PE format will not allow it.  */
  /* DWARF 1.1 and DWARF 2.  */
  .debug_aranges BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_aranges)
  }
  .debug_pubnames BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_pubnames)
  }
  /* DWARF 2.  */
  .debug_info BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_info) *(.gnu.linkonce.wi.*)
  }
  .debug_abbrev BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_abbrev)
  }
  .debug_line BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_line)
  }
  .debug_frame BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_frame)
  }
  .debug_str BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_str)
  }
  .debug_loc BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_loc)
  }
  .debug_macinfo BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_macinfo)
  }
  /* SGI/MIPS DWARF 2 extensions.  */
  .debug_weaknames BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_weaknames)
  }
  .debug_funcnames BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_funcnames)
  }
  .debug_typenames BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_typenames)
  }
  .debug_varnames BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_varnames)
  }
  /* DWARF 3.  */
  .debug_ranges BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_ranges)
  }
}


--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii

--
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/
--a8Wt8u1KmwUX3Y2C--