Re: [PATCH] move __gmon_start__ call out of .init section

[David Mosberger <davidm at napali dot hpl dot hp dot com>]

>>>>> On Thu, 7 Nov 2002 13:45:47 -0800, Roland McGrath <roland@redhat.com> said:

  >> The patch below changes the ia64 initfini.c such that the call to
  >> __gmon_start__ is done via the .init_array section (if
  >> available).  The idea here is to keep the .init/.fini empty
  >> (apart from prologue/epilogue) so as to ensure that the unwind
  >> info is always correct.

  Roland> Can you elaborate a bit on the problem you are addressing
  Roland> here?

The problem is that the unwind info for the .init/.fini section will
be incorrect if it contains any function call.  It's easiest to make a
concrete example:

 - on ia64, if there is no explicit unwind info for a piece of code,
   the assumption is that the return address is stored in branch
   register b0

 - if .init contains a call, then the value in the return address
   register (b0) needs to be saved somewhere (normally on the memory
   stack); but since .init is created "dynamically" by the linker, the
   unwind info for .init will be wrong and the fact that b0 has been
   saved on the memory stack won't be recorded anywhere

Of course, one could hack the linker to correct the unwind info but
this would be fragile and ugly, so the preferred solution is to
deprecate .init/.fini alltogether and to use .init_array/.fini_array
instead (which is much easier to use anyhow).

  Roland> This seems wrong to me, in that the user program might put
  Roland> some code into the .init section and then __gmon_start__
  Roland> would come after it instead of before.

That's true, but .init is deprecated on ia64 anyhow.  If legacy code
doesn't get profiled because it was using .init, I doubt that's a big
loss.

Perhaps the call could be moved into .preinit_array?  I'm not entirely
sure whether that would be safe though.

	--david