Mail Archives: cygwin/1999/09/27/15:17:02
Paul Sokolovsky <paul-ml AT is DOT lg DOT ua> writes:
>
> 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:
Paul,
Reloc overflow is a problem with all linking, but I don't know off hand
if reloc overflow is the only problem with incremental linking. I fear
there are others as well, and since incr linking is never quite as well
tested as "regular" linking, the bugs come out slowly over time.
> 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).
I believe this is fixed in the snapshots, but I need to make sure.
> 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:
Ah, the joys of "interesting" comdat issues in the current binutils.
There's work on going, so please have patience. I'm sure Ian is still
chugging through the large set of patches from Donn Terry ...
> So, I would like to ask is this a bug in pe/coff handling or ld
> just cannot catch up with g++ ?
The issue is really comdat handling more than having to catch up to
g++. Once comdats are handled correctly, g++ support will implicitly
work.
What binutils snapshot did you try these with?
Regards,
Mumit
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -