Mail Archives: djgpp/1997/07/07/12:14:22
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.
- Raw text -