public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: mahamud@cs.cmu.edu
To: Steve Chamberlain <sac@transmeta.com>
Cc: binutils@sources.redhat.com
Subject: Re: incremental ld ?
Date: Sat, 15 Jul 2000 16:14:00 -0000	[thread overview]
Message-ID: <14704.59938.687727.425299@marr.ius.cs.cmu.edu> (raw)
In-Reply-To: <20000715154748.89DEE8CB2F@vole.transmeta.com>

thanx for the prompt reply!

    >> Let me guess - it's a large g++ project compiled with debygging
    >> ?  I had something like this last year.  I fixed it by sending

yes, a module for the mozilla browser project. 

    >> in a patch to ld which did better hashing for the debugging
    >> info (which halved the time) and compiling fewer files with

i assume that this patch has been incorporated into the current ld.

    >> debugging turned on (which got the time to somewhere just
    >> beyond painful).

i did'nt think of this before. i have tried it now, it cuts down on the space
a lot - from ~50MB to ~14MB, but it shaved off only ~2 min from the 
12 min link time.

    >> (My next step would have been to split the binary into
    >> different shared objects)

the code is divided into lots of shared objects,
but the problem i am facing is while creating another shared object
from a bunch of objects and other shared objects. 
most of the object files are not modified. if i wanted to create a
final executable, then i would use your suggestion and create
a new shared object from the object files that don't get modified
and use that along with other shared objects and the 
object files that get modified to create the executable. 

i have tried an alternative suggested by the ld man page.
i used 'ld -Ur' to create a relocatable file from all the object files 
that don't get modified. the man page claims that further linking should be
faster with such a relinkable object file. i then create the shared
object i want with this relinkable object file 
along with the modified object files (as
well as other shared objects). Surprisingly things get worse, ~20 min
vs. 12 min. without 'ld -Ur'. am i doing something wrong ?

while on this topic of relinkable objects, i would like to ask why 
i cannot link in shared objects with the 'ld -Ur' option ?
i can only link in these shared objects while creating the final
shared object using a normal ld. is this a limitation of the current
implementation of gnu ld or is it fundamentally not possible (i am not 
a compiler/linker expert). i would think that if it was possible
to link in shared objects with 'ld -Ur' then a lot more symbols could
get resolved upfront, thus avoiding having to resolve 
these symbols while creating the final shared object. 

any comments and help would be appreciated.

thanx
- shyjan


       reply	other threads:[~2000-07-15 16:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mahamud@marr.ius.cs.cmu.edu>
     [not found] ` <200007151013.DAA22014@neosilicon.transmeta.com>
     [not found]   ` <20000715154748.89DEE8CB2F@vole.transmeta.com>
2000-07-15 16:14     ` mahamud [this message]
2000-07-15  3:12 Shyjan Mahamud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=14704.59938.687727.425299@marr.ius.cs.cmu.edu \
    --to=mahamud@cs.cmu.edu \
    --cc=binutils@sources.redhat.com \
    --cc=sac@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).