MIPS16: AS wouldn't assemble gcc output.

[Mike Stump]

> From: "Dmitri Makarov" <dim@windriver.com>
> Date: Fri, 3 Mar 2000 11:48:04 -0800

> Why indeed it so happens that gcc separately outputs a list of ascii
> strings that are used in class member functions and then outputs in
> individual sections member function difinitions.  Why wouldn't it
> put the strings close to where they are used.  It's more like "how
> to make it do that?" and not really "why?" I'm asking.

I'm sending this to the list as well, as others might have some input.
I'm might not be the best person to answer this (Hi Gavin), but I'll give
it a try.

A while ago, there were no such things as link once sections (nor
sections).  This explains why it `worked' before.  When adding them,
we missed this subtly.  Anyway, we need to think about how we can
change the code gen strategy to fall in line with Ian's thinking
(assuming no one wants to argue against it).  I can think of a couple
of solutions.

One way would be to shove constant pool items for things in sections
into the section that references them, another one would be to be
aware the references that cross a section boundary and avoid using the
constructs that in general can't be expected to span that far...

Now, why does it generate strings far away, because they are collected
on a per translation unit basis, and emitted if used.  Because they
are shared among all entities in the entire file, they aren't `for'
any given function.  One cannot think about fixing the bug, without an
in-depth understanding of why the compiler generates the things it
does.  Otherwise, one can get into a bug pushing fest, which is worse
than the original bug.

I can't answer the how to fix it, until I know which way is the right
way to fix it.  After we discover that, then I can say more about the
solution.

I checked out the codegen, and for normal functions, it does indeed
place strings in the .text section to try and get them close.

I have a feeling it is easier to generate a longer style reference
during codegen, than it would be to `move' the data item closer.  This
bug also shows up in plain C (see testcase below).  So, it isn't a bug
with C++.  If we fix it that way, then you need to check the section
of the reference to see if it is the same as the section where the
data was placed, and if it differs, then gen the long sequence.  To
track it down, set a breakpoint on movsi, and step through it and
watch how it generates the code.  It should become obvious at that
point.  If we move the constant, then you're going to have to be
prepared to move any/all constants, not just this one case.

What do others think?


extern int printf (char*);
 
__attribute__ ((section ("f1"))) void gf1 () 
{
  printf ("gf1");
}

void gf1a () 
{
  printf ("gf1");
}