PR gcc/7618: Support MI thunks in the MIPS backend

Ian Lance Taylor ian@wasabisystems.com
Wed Jan 14 20:42:00 GMT 2004


Richard Sandiford <rsandifo@redhat.com> writes:

> > Clearly, when using explicit relocs, it should be possible to do lazy
> > binding even when using thunks.  However, gas doesn't appear to
> > generate them.  I'm not entirely sure why.  I think it's because
> > tc_gen_reloc() relaxes CALL16 to GOT_DISP, but I haven't investigated
> > why this happens.
> 
> As I understand it, the address of both the thunk and the function
> it calls are stored in vtables.  Anything like that would be enough
> to stop lazy binding.

Good point.  (Though I still think there is an assembler bug.)

> > And here is a version which works for all cases I've tested.
> 
> Hmm... it doesn't look like you're setting up $gp for !TARGET_NEWABI.

Hmmm, you're right.  I copied the code from mips_expand_prologue(),
but not from mips_output_function_prologue(), since the latter
function is, in fact, called.  However, that function only sets up $gp
if cfun->machine->global_pointer > 0.

I can fix that by throwing in a call to compute_frame_size().  But
we're getting increasingly hackish.

> Also, it looks like the TARGET_NEWABI version will use $gp as the
> global pointer.  That's not right, since $gp is a call-saved register.
> (Note that if you use a call-clobbered register instead, you need to
> tell the assembler about it, at least when using assembler macros.)

Bother.  Here again I can't use the existing machinery, because it
assumes that it can allocate a new register (in, e.g.,
mips_unspec_offset_high()).

The problem with generating assembler code, as in my original patch,
is that we need to recreate all the ABI stuff manually.  The problem
with generating RTL, as in the current patch, is that we still need to
recreate all the ABI stuff manually, because the existing machinery
doesn't work in the very limited circumstances available to this code.

Ian



More information about the Gcc-patches mailing list