https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #112 from dave.anglin at bell dot net ---
Hi Cameron,
We have to fix bootstrap compiler so we have a working g++ with one only
(.weak) support.
I think the offset in the branch relocation possibly comes from the fact that
on ia64-hpux we need a
.type declaration for external references. We have in pa64-hpux.h:
/* The type of external references must be set correctly for the
dynamic loader to work correctly. This is equivalent to the
HP assembler's .IMPORT directive but relates more directly to
ELF object file types. */
#undef ASM_OUTPUT_EXTERNAL
#define ASM_OUTPUT_EXTERNAL(FILE, DECL, NAME) \
pa_hpux_asm_output_external ((FILE), (DECL), (NAME))
#define ASM_OUTPUT_EXTERNAL_REAL(FILE, DECL, NAME) \
do { \
if (FUNCTION_NAME_P (NAME)) \
ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, "function"); \
else \
ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, "object"); \
default_elf_asm_output_external (FILE, DECL, NAME); \
} while (0)
I suspect the branch tried to call an "object" rather than a "function".
You can check whether functions have correct type using nm.
Unfortunately, the above won't work directly because of the function name
encoding
used on pa. Maybe you can look at aCC to see the assembly output it generates
to a
call to a weak function.
I don't have time today to figure out the linkonce issue below.
On 2019-07-26 10:57 p.m., cameron.heide at betasystems dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #111 from C. Heide <cameron.heide at betasystems dot com> ---
> (In reply to dave.anglin from comment #110)
>> Okay, this is problem linkonce sections. I think we need to figure out why
>> ia64_hpux_function_section
>> isn't working. Maybe try return text_section in ia64_hpux_function_section.
> I gave that a try (just "return text_section;" in there) but it looks like
> something is still generating linkonce sections:
> Output (during compile of eh_alloc.cc):
>> /var/tmp//ccOX5Jzg.s: Assembler messages:
>> /var/tmp//ccOX5Jzg.s:8406: Error: can't resolve `.text' {.text section} -
>> `.gnu.linkonce.t._ZN9__gnu_cxx24__concurrence_lock_errorD0Ev' {*UND* section}
>> /var/tmp//ccOX5Jzg.s:8407: Error: can't resolve `.text' {.text section} -
>> `.gnu.linkonce.t._ZN9__gnu_cxx24__concurrence_lock_errorD0Ev' {*UND* section}
>> /var/tmp//ccOX5Jzg.s:8411: Error: can't resolve `.text' {.text section} -
>> `.gnu.linkonce.t._ZN9__gnu_cxx24__concurrence_lock_errorD0Ev' {*UND* section}
> Generated assembly:
>> .file "eh_alloc.cc"
>> .pred.safe_across_calls p1-p5,p16-p63
>> .section .text, "ax", "progbits"
>> .Ltext0:
>> .section
>> .gnu.linkonce.r._ZNK9__gnu_cxx24__concurrence_lock_error4whatEv.str1.8,"aMS",@progbits,1
>> .align 8
>> .LC1:
>> stringz "__gnu_cxx::__concurrence_lock_error"
>> .section .text, "ax", "progbits"
>> .align 16
>> .weak _ZNK9__gnu_cxx24__concurrence_lock_error4whatEv#
>> .proc _ZNK9__gnu_cxx24__concurrence_lock_error4whatEv#
>> _ZNK9__gnu_cxx24__concurrence_lock_error4whatEv:
>> etc...
> though I think the error is referring specifically to these (debug?) entries
> later on:
>> .LLST0:
>> data4.ua
>> .LVL6-.gnu.linkonce.t._ZN9__gnu_cxx24__concurrence_lock_errorD0Ev#
>> data4.ua
>> .LVL7-.gnu.linkonce.t._ZN9__gnu_cxx24__concurrence_lock_errorD0Ev#
>> data2.ua 0x2
>> data1 0x90
