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 X-pair-Authenticated: 217.4.28.105 Message-ID: <3D2EE0C2.78D6@multimediaware.com> Date: Fri, 12 Jul 2002 15:59:30 +0200 From: Wolfgang Hesseler MIME-Version: 1.0 To: egor duda Subject: Re: Bug: BSS segment in COFF files References: <3D2EA2E2 DOT 2881 AT multimediaware DOT com> <8772121004 DOT 20020712145134 AT logos-m DOT ru> <3D2EBFC2 DOT 6973 AT multimediaware DOT com> <9975891676 DOT 20020712155424 AT logos-m DOT ru> <3D2EC616 DOT 19DA AT multimediaware DOT com> <9382195250 DOT 20020712173928 AT logos-m DOT ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > >> >> If you run gcc with '--save-temps' flag, and then look into > >> >> 'yourfile.s' file, you'll see that uninitialized data is tagged as > >> >> "common" (using '.comm' directive) and is put to bss only by linker > >> >> when final executable is created. To turn this feature off, use > >> >> '-fno-common' flag when compiling your object file. I just noticed that this doesn't help at all. When analyzing the object file with IDA you'll see that the BSS section has length 0. Thus, when you link several object files together, all variables are at the same memory position. I think it's a problem with the Assembler that doesn't generate valid COFF files. BTW, when compiling the same program under Linux the BSS section is not 0. So, it seems that the problem is Cygwin (COFF) specific. So far, the only way to reserve memory for a variable is to make it 0-initialized. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/