Re: PATCH: hpux NM_FLAGS

[law at redhat dot com]

  In message <200105080400.AAA07565@hiauly1.hia.nrc.ca>you write:
  > > The $CODE$ subspace names are for section symbols.  I can think of ways
  > > that we could get section symbols for those truncated section names.  Hmm
  > ,
  > > let me think on this a little.
  > 
  > Here is an example of the problem:
[ ... ]
Thanks for the pointer to an example.  Ugh.  This sucks.

I'm awful close to removing support for arbitrary sections in SOM.  The
benefits for SOM are relatively small and they're turning out to be a
major pain in the *()&@#$.

Benefits:

  1. With some work it is possible to use arbitrary section support to
  specify ordering of functions and variables in an object file. 
  However, it's bloody hard since SOM doesn't have a nice linker script
  language -- it takes a fair amount of knowledge of how the SOM linker
  works to achieve this.

That's it.  There is no garbage collection in the SOM linker, so we don't
get the one thing that actually use generally useful with arbitrary section
support.


Pitfalls:

  1. HP's tools (for example NM) are known to have bugs such as
  core dumping when presented with long section names.  So far
  we have only seen this with NM, but I wouldn't be shocked if
  there's other examples waiting in the weeds.

  2. HP's linker will create an unloadable executable if you have two
  subspaces with the same name in different spaces.

  3. Problems with false positive matches in collect2 if we try to work
  around problem #1 above.

  4. Maintenance headaches because the HP assembler can't handle
  subspace names that do not begin/end with '$'.  [ I'm not kidding. ]

  5. There's problems with -ffunction-sections + -g + EH.  Try to bootstrap
  the mainline and you'll understand :(


Basically, I don't see a whole lot of reasons to keep arbitrary section
support for SOM.

jeff