Re: [patch] TLS support for hppa-linux

[Randolph Chung <randolph at tausq dot org>]

> > +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/