Re: [PATCH/RFA] Java: DWARF2 exception on sh-linux

[kaz Kojima <kkojima at rr dot iij4u dot or dot jp>]

"Stephen Clarke" <stephen.clarke@earthling.net> wrote:
> From: "Alexandre Oliva"
> Sent: Thursday, November 21, 2002 5:28 PM
>> On Nov 21, 2002, kaz Kojima <kkojima@rr.iij4u.or.jp> wrote:
>> 
>> > * libtool.m4 (linux-gnu*): Set lt_cv_deplibs_check_method to
>> > pass_all also for sh*.
>> 
>> Since this is in the libtool tree already, it's ok to put it in.
>> However, before you check this in, please sanity-check that it is
>> actually safe to link any non-PIC code into SH shared libraries.  If
>> there's any case in which this can possibly break, then pass_all is
>> not the right thing to use, and we'd better arrange for it to be taken
>> out of libtool mainline.
> 
> I'm not at all familiar with this area, or what is meant by "safe", but
> it may be worth pointing out that there could be problems with
> putting non-PIC SHmedia code in shared libraries.  The
> R_SH_IMM_LOW16 and R_SH_IMM_MEDLOW16 relocations
> are not handled in bfd/elf32-sh.c when creating a shared object.
> (Similarly for the MEDHI16 and HI16 relocations in elf64-sh64.c.) 
> As far as I can tell, this is just a case of not implemented
> because noone has yet had a need for it, rather than there being a
> fundamental reason why it can't be supported.

Sorry for my slow response. It took the several days to play and
understand these SHmedia relocations as I was fallen into the pitfall
of a binutils problem.

Your point is right. My understanding is that the current ld can't
make a correct (working) shared library if these relocations survive.
It seems that something like R_SH_RELATIVE_*LOW16 relocations are
needed to handle them, though I might be wrong.

I'm inclined to use sh | sh[34] instead of sh* at this point.
Alexandre, how do you think about?

Regards,
	kaz