https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100754
--- Comment #2 from Martin <mgaron at pleora dot com> ---
Hi Richard,
Thanks for the quick response. I had to do a bit of research to try to properly
express my suspicions.
1st the function from the dispatch table is properly called. Not problems
there:
000001a4 <_ZThn4_N7Derived9ModifyIntEi>:
It's the body of this reference function that seems wrong. It should do a local
relative jump to the implementation address, but instead performs a
global relocation, making the implementation function's address change based on
the current shared object it's being called from.
// Base.
int ModifyInt(int value) override;
1a4: 30a5fffc addik r5, r5, -4
1a8: b0000000 imm 0
1a8: R_MICROBLAZE_GOT_64 $LTHUNK2
1ac: e9940000 lwi r12, r20, 0
1b0: 98086000 bra r12
We x-compile and natively compile similar code on a few platforms and only the
microblaze one generates such code. For instance, the sample program attached
in the bug entry generates the following code on different compilers:
//proper local jump from inside the reference function aarch64, gcc8.2.0:
00000000000000d8 <_ZThn8_N7Derived9ModifyIntEi>:
d8: d1002000 sub x0, x0, #0x8
dc: 17fffff7 b b8 <_ZN7Derived9ModifyIntEi> // jumps to
implementation function.
//proper local jump from inside the reference function aarch64, gcc 8.2.0:
00000128 <_ZThn4_N7Derived9ModifyIntEi>:
128: e2400004 sub r0, r0, #4
12c: eafffff1 b f8 <_ZN7Derived9ModifyIntEi> // again
//proper local jump from inside the reference function x86_64, gcc 5.4.0:
00000000000000c8 <_ZThn8_N7Derived9ModifyIntEi>:
c8: 48 83 ef 08 sub $0x8,%rdi
cc: eb e6 jmp b4 <_ZN7Derived9ModifyIntEi> // and
again...
So these last 3 compilers properly generated the local relocation, where the
microblaze code generates global relocation for that thunk. Wouldn't that point
to the microblaze backend?
Also, it is highly suspicious that inverting the order of the parent classes
changes the generated code. And that would point at the gcc front end?
