Date: Mon, 7 Jul 1997 19:06:57 +0300 (IDT) From: Eli Zaretskii To: Andrew Crabtree cc: djgpp AT delorie DOT com Subject: Re: Debugging version of C library In-Reply-To: <199707071524.AA299059083@typhoon.rose.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 7 Jul 1997, Andrew Crabtree wrote: > Stories like this really, really scare me. I have never heard of this > happening. The only guess I would have to this behaviour is > libgcc (or some other library or file ) needed another print type function > that was declared in the same .o file as printf, so that was brought in. The problem was not with `printf' itself, but with a call to it in a function I wanted to debug. I inserted the call to `printf' to make sure my modified version is called, but the string was not printed, indicating that the old version from libc.a was still called. It must have something to do with the one-pass way of ld.exe, but I never had time (or incentive) to investigate; I don't have the luxury to live dangerously with my projects. > Did you try (can't remeber exact switch here) the switch to tell the > linker to spit out all the details for resolving symbols. No, I didn't, and in many cases this is much harder than to replace the function in the library (especially if you use complex Makefiles). > The reason I ask is I too use the replace one file > method from libc, but I haven't run into any problems yet. I am not just > changing the -g flag, but actually stubbing out or modifying code, so I > keep my original Libc intact. You can always make a read-only copy of the original libc.a, and copy from that after you are done debugging. IMHO, replacing the functions in the library is much simpler than risking subtle bugs which I described. Many people don't know by heart which library functions are defined on which source modules, and won't easily grasp the implications of several functions being on the same source file when they debug like this.