------- Comment #68 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-30 02:48 ------- Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c
> > If the encoding for function names is getting stripped, then > > ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly. > > Not sure what you meant by that comment; that's not what happens here AFAICT. > I stated that output_operand does not see the same symbol_ref as was passed to > the rtl insn expander, so target-specific code is needed just like for Darwin > - or maybe it's just missing in generic code, for the constant pool. I believe that the only special aspect of symbol_ref processing on the 32-bit hppa port is the symbol name encoding. There's also some flag bits. Other than that, it's not clear why output_operand would see something different from what was passed to the rtl insn expander. There's nothing new in the hppa backend wrt symbol references. Besides the .import issue, function pointers have to point to a function descriptor (not the real code). This is done using a plabel which is a relocation which tells the linker to create a pointer to a function descriptor. This happens automatically if the output for the function pointer output uses assembler_integer (assuming the name encoding is correct). Because the output of .import directives is a two stage process, there might be an issue if a symbol_ref was garbage collected after the assemble_external call. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
