Mail Archives: djgpp-workers/2000/02/24/11:13:46
On Thu, 24 Feb 2000, Eli Zaretskii wrote:
[...]
> causes the program to run to completion after the `s' command, instead of
> stepping into dfunc().
My first guess: the new optimizer might have inlined the whole thing into
so small a piece of assembly that there is no useful division into
function dfunc(), func() and sqrt() left.
Have you had a look at the assembly source the example compiles to?
> FWIW, the command to compile was "gcc -Wall -O -g -o fpfunc fpfunc.c".
Or checked what happens if you don't optimize at all?
[I'd test those myself, but I don't have access to any DOS-like box,
right now]
> This might seem like a toy problem, but I have seen similar problems in
> much larger programs, like Emacs: some breakpoints simply don't break
> even though I *know* the program passed those points. Come to think of
> it, all the cases I saw were when the breakpoint was set on the entry to
> a function. Again, when compiled with GCC 2.7.2.1, the breakpoints
> behave like expected.
Another, largely unrelated suspicion of mine was triggered by this. Some
of you may remember the problems I reported when I tried to use 'gprof' of
binutils 2.8.1 to the full extent of its possibilities, including
line-by-line and basic-block based profiling. I had noticed that there was
a discrepency in the way line-number based debug information was handled
by the BFD library, between COFF and .stabs symbols. The address of the
code belonging to a given line number was stored either as an offset to
the 'vma' of the code segment, or as the full address, 'vma + offset'.
At that time, Robert Hoehne told me that GDB has its own code to handle
the mapping between line numbers and code addresses. It just might be
that since then, the new ports of GCC, GDB and/or binutils have broken
this GDB code in a way similar to how BFD version 2.8.1 was broken.
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -