[patch] TLS support for hppa-linux
Randolph Chung
randolph@tausq.org
Thu Jun 30 14:47:00 GMT 2005
> > +hppa_tls_call (rtx arg)
> > +{
> > + rtx ret, r26, r28;
> > +
> > + r26 = gen_rtx_REG (Pmode, 26);
> > + r28 = gen_rtx_REG (Pmode, 28);
> > + ret = gen_reg_rtx (Pmode);
> > +
> > + emit_move_insn (r26, arg);
> > + emit_library_call_value (gen_tls_get_addr (), NULL_RTX,
> > + LCT_CONST, Pmode, 1, r26, Pmode);
> > + emit_move_insn (ret, r28);
>
> This seems very wrong. Either r26 and r28 are part of the normal
> function call sequence and you don't have to create hard registers
> here yourself, or using emit_library_call_value is wrong because
> it'll force the values into incorrect registers.
agreed, this is wrong. will fix.
> > + emit_libcall_block (insn, ret, r28, addr);
>
> emit_libcall_block should be redundant with the block emitted by
> emit_library_call_value.
ack.
> > +/* Non-TLS symbolic references. */
> > +#define PA_SYMBOL_REF_TLS_P(RTX) \
> > + (GET_CODE (RTX) == SYMBOL_REF && SYMBOL_REF_TLS_MODEL (RTX) != 0)
>
> Either in legitimize address or in your move expanders, you must
> handle (const (plus (symbol_ref "tlssym") (const_int))). There
> should be an existing test for this.
I don't understand this point, what do you think is missing?
I modelled the above macro predicate from sparc. It replaces calls to
"tls_symbolic_operand" in places where we cannot call that predicate in
the code.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
More information about the Gcc-patches
mailing list