Re: [9fans] Good enough approximation for ape/pcc

["Russ Cox" <rsc@swtch.com>]

> | The Plan 9 C libraries already provided a mechanism
> | for finding the caller - getcallerpc(2).
>
> What happens when there is no caller because the function got inlined?

Doesn't happen.  One of the many nice things about the Plan 9 compilers.

In fact, I just added two instructions to an assembly routine in
libmp *only* so that stack traces would work when starting in that
routine.  I probably slowed it down by some miniscule fraction of
a percent, and I certainly made the code a few bytes bigger.  A lose/lose,
except that now the code is more debuggable, and that's the ultimate win.

> Obviously with compiler support you could get the right effect, but
> wouldn't it be a bit more work?

Dealing with all this crap while working on plan9port has soured me
even more on the current state of mainstream programming.
I learned to program using 16-bit DOS compilers.  And they were better!
I could rant about this and tell war stories for hours.  The short
version is this.

Gcc does all these kinds of optimizations and more.  I can't imagine
what they're optimizing for.

    gcc-developer time?  many hours went into writing that code.
    compile time?  gcc is certainly getting slower
    correctness?  the code may be correct but the debugging output
       (stack traces from gdb) gets less and less reliable
    my time?  i've lost hours upon hours because of the increase
       in compile time and the unreliability of the debugging environment
    generated code speed?  it's not cpu intensive in the first place,
       or i would have said -O99 or something like that

So let's see.  For negligible benefit that I indicated wasn't worth
the effort via a compiler flag, they've wasted hours of their
own time and hours of my time.  Sounds like a bad deal to me.

In a gcc world, I'm sure __func__ and its ilk make tons of sense.
I want no part of such a world.

Russ