Re: PATCH: hpux NM_FLAGS

[law at redhat dot com]

  In message <200105111938.PAA12882@hiauly1.hia.nrc.ca>you write:
  > I agree that the current scheme is a major headache.  Ordering of
  > functions and data would be a lot easier to achieve if there was sort
  > __attribute__.  The integer sort value could be used as part of the
  > the subspace name.  For example, the subspace name for a sort key of
  > 32 could be "$CODE_32$".
Yea, that was one of the original things I played with.  The tricky part
is some of the sort keys are special and the ones that are special aren't
documented anywhere.

  > It would seem like a pain in the neck to try process the link order
  > file generated by fdp.  I haven't looked at this at all.  If the sections
  > were just numbered, would it still be possible to do ordering?
You can still do ordering, but you lose the fine grained ability to place
each function where you want it (which was the whole point behind the
original -ffunction-sections).

The easiest way to do ordering, if each function is in its own section and
the section's name is based on the function name is to create a new .o 
file which has the ordering of sections you want.  ie, you declare each
section in the order you want, but don't put any contents in the sections.
You then put that special .o file first on the link line.  From that point
on, the right thing "just happens".

  > Thought the linker "-O" option would turn-on dead procedure elimination.
It didn't last I looked, but that was years ago.  I guess I could look again.

If the linker has dead procedure elimination now, then we're still OK
because while we won't be supporting named arbitrary sections, we still
place each function in its own $CODE$ section.  Which would allow for
dead procedure elimination if the linker supported it.

jeff