Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Date: Sat, 25 Sep 1999 22:58:03 +0300
From: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
X-Mailer: The Bat! (v1.32) S/N 34D3AC61
Reply-To: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
X-Priority: 3 (Normal)
Message-ID: <3956.990925@is.lg.ua>
To: Mumit Khan <khan AT thor DOT xraylith DOT wisc DOT edu>
CC: cygwin AT sourceware DOT cygnus DOT com
Subject: Re[2]: ld or gcc failing?
In-reply-To: <199909242130.QAA25818@mercury.xraylith.wisc.edu>
References: <199909242130 DOT QAA25818 AT mercury DOT xraylith DOT wisc DOT edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Mumit,

Mumit Khan <khan AT nanotech DOT wisc DOT EDU> wrote:

>> > ld -r -o Dobj3.a do243d.o re247d.o in245d.o bo251d.o ch249d.o po253d.o
>> etc. etc.

MK> The problem here, and Emmanuel has already filed a bug report on this,
MK> is that GNU as/ld on x86-win32 can only handle 16-bit relocations, and

    Is reloc overflow the only problem with incremental linking? I was
unable to use it at all. Never tried for trivial example, but using it
when it is really needed, e.g. when linking megabytes of C++ code
gives nonsense. From quick look, following wrong things are being done:

      Groupping of subsections is performed. This is bad idea because
different subsections can have different attributes.

      Anything except .text,.data,.dtor,.ctor,.bss seem to be
discarded (.drectve, mainly).

      For example, look what nonsense gives linking 6 objects of total
size 300k and full of .text$ comdats for dllexported inlines and
.data$ comdats for virtual tables:
---
a.o(180k):     file format pe-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000145f8  00000000  00000000  000000dc  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, CODE, LINK_ONCE_DISCARD
  1 .data         00000a00  000145f8  00000000  000146d4  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, DATA, LINK_ONCE_DISCARD
  2 .dtor         0000000c  00014ff8  00000000  000150d4  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, CODE
  3 .ctor         00000010  00015004  00000000  000150e0  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, CODE
  4 .bss          00000020  00015014  00000000  00000000  2**2
                  ALLOC
---

   So, I would like to ask is this a bug in pe/coff handling or ld
just cannot catch up with g++ ?

MK> Unless someone fixes it, it'll remain a bug.

MK> Regards,
MK> Mumit


Best regards,
 Paul                            mailto:paul-ml AT is DOT lg DOT ua



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com