This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: ld-auto-import memory bug fixing
- To: "Binutils" <binutils at sources dot redhat dot com>
- Subject: RE: ld-auto-import memory bug fixing
- From: "Ralf Habacker" <Ralf dot Habacker at freenet dot de>
- Date: Fri, 7 Sep 2001 10:58:47 +0200
> -----Ursprüngliche Nachricht-----
> Von: nickc@north-pole.nickc.cambridge.redhat.com
> [mailto:nickc@north-pole.nickc.cambridge.redhat.com]Im Auftrag von Nick
> Clifton
> Gesendet am: Freitag, 7. September 2001 10:43
> An: Ralf Habacker
> Cc: Binutils
> Betreff: Re: ld-auto-import memory bug fixing
>
> Hi Ralf,
>
> > When linking a dll with g++, it calls collect which calls ld, but ld
> > is not in the ps list.
> >
> > Can anynone tell me how I can even though debug ld with gdb ?
>
> The best method would be to capture the command line that collect2
> uses to invoke ld and then reproduce that invocation inside gdb. If
> you pass -debug to collect2 it should show you the commands that it is
> executing.
Thanks, I will try. With - debug you mean -Wl,--debug on g++ line ?
>
> Another thing you can try is to add print statements to ld. I know
> that this is not as sophisticated as using gdb, but it is a very
> effective debugging tool.
>
Yes, I have done this too, but on linking big dll's/apps, the output seems to be
buffered, so I can't see in realtime, where ld currently is. I will try to use
fflush after printing.
Debugging state: I have tried to debug ld with a big lib, but unfortunally gdb
need much memory to load all the dll, that ld break very early in linking, so I
can't capture the origin problem.
Any ideas ?
Ralf
> Cheers
> Nick
>
>