categorize_decl_for_section bogosity

["Dave Korn" <dk at artimi dot com>]

    Hi everyone,

  I suspect the answer is going to be something like 'Yeh, we know' or 'You
just can't use it like that', but since I've just spent most of the
afternoon tracking this one down I'd better share what I've found out.

  Anyway, take a look at this excerpt from categorize_decl_for_section:

---------------snip---------------
static enum section_category
categorize_decl_for_section (decl, reloc, shlib)
     tree decl;
     int reloc;
     int shlib;
{
  enum section_category ret;

....snip clauses that handle functions and string consts....
  else if (TREE_CODE (decl) == VAR_DECL)
    {
      if (DECL_INITIAL (decl) == NULL
	  || DECL_INITIAL (decl) == error_mark_node)
	ret = SECCAT_BSS;
      else if (! TREE_READONLY (decl)
	       || TREE_SIDE_EFFECTS (decl)
	       || ! TREE_CONSTANT (DECL_INITIAL (decl)))
	{
	  if (shlib && (reloc & 2))
	    ret = SECCAT_DATA_REL;
	  else if (shlib && reloc)
	    ret = SECCAT_DATA_REL_LOCAL;
	  else
	    ret = SECCAT_DATA;
	}
....else categorize as some kind of r/o data section....
---------------snip---------------

  Now my problem is that this interacts badly with old-style K'n'R
common/bss symbols.  Consider a declaration like this:

extern const UQItype __clz_tab[];

  Because there's no initialiser, the test for DECL_INITIAL == NULL is
satisfied and the code above assumes it's a .bss section object.  This is a
false inference, and I _think_ it's the presence of the extern that makes it
so, isn't it?  If there was no extern there, this would be a standard
uninited common, and so should go into bss; but because it's only an extern
definition, the actual declaration in another module (if there is a
declaration in another module) will take priority over where the array
actually ends up; it's only if *every* other module declared it extern and
uninit'ed that it will truly end up in the .bss.

  Also, the suggestion that a const object might end up in the .bss section
is a) a bit silly b) false in this particular case and c) a real pain in the
wotsits to my heuristics that are trying to deduce short-vs.-long
reachability.

  I've run into this before.  This false inference is the reason why if you
say

        mem = DECL_RTL (decl);
        symref = XEXP (mem, 0);

you don't always find that RTX_UNCHANGING_P (mem) is true when
decl_readonly_section (decl) is, which you might naively expect.  In fact,
it happens for the above case that they are both false, which is soooo much
what I don't want.

  Anyone got any thoughts on this?  I'm tempted to look out for whatever
flag it is that tells me that this is an extern declaration and add "&& !"
that test to the DECL_INITIAL (decl) == NULL clause, but that might have
knockon effects.  Has anyone else considered this issue before?


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....