* Re: Maybe another or1k bug [not found] ` <6bc67759-18c2-bca5-bdb2-c637e873b8ab@benettiengineering.com> @ 2021-06-17 23:41 ` Stafford Horne 2021-07-07 21:06 ` Stafford Horne 0 siblings, 1 reply; 8+ messages in thread From: Stafford Horne @ 2021-06-17 23:41 UTC (permalink / raw) To: Giulio Benetti; +Cc: Openrisc, GNU Binutils, Richard Henderson On Tue, May 25, 2021 at 01:03:37AM +0200, Giulio Benetti wrote: > On 5/25/21 12:34 AM, Stafford Horne wrote: > > I'm cc'ing the list so there is a record, and other experts could come > > in if they like. > > Ah yes, pardon > > > Ok, I'll take a look. > > > > Thanks, these are always fun for me. > > That's great :-) So I finally had some time to look at this. I think I understand the issue, but not sure of the fix yet. Let me explain for the record: 1. The error: When building openal we get the following: /home/buildroot/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/source.cpp.o: pc-relative relocation against dynamic symbol alSourcePausev /home/buildroot/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/source.cpp.o: pc-relative relocation against dynamic symbol alSourceStopv /home/buildroot/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/source.cpp.o: pc-relative relocation against dynamic symbol alSourceRewindv /home/buildroot/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/source.cpp.o: pc-relative relocation against dynamic symbol alSourcePlayv /home/buildroot/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: final link failed: bad value 2. This is caused by this code in bfd for or1k. case R_OR1K_INSN_REL_26: case R_OR1K_PCREL_PG21: case R_OR1K_LO13: case R_OR1K_SLO13: /* For a non-shared link, these will reference either the plt or a .dynbss copy of the symbol. */ if (bfd_link_pic (info) && !SYMBOL_REFERENCES_LOCAL (info, h)) { _bfd_error_handler (_("%pB: pc-relative relocation against dynamic symbol %s"), input_bfd, name); ret_val = false; bfd_set_error (bfd_error_bad_value); } break; 3. The code being linked is this from `objdump -dr`: 0000a198 <alSourcePlay>: a198: 9c 21 ff f8 l.addi r1,r1,-8 a19c: d4 01 18 00 l.sw 0(r1),r3 a1a0: e0 81 08 04 l.or r4,r1,r1 a1a4: d4 01 48 04 l.sw 4(r1),r9 a1a8: 04 00 00 00 l.jal a1a8 <alSourcePlay+0x10> a1a8: R_OR1K_INSN_REL_26 alSourcePlayv a1ac: a8 60 00 01 l.ori r3,r0,0x1 a1b0: 85 21 00 04 l.lwz r9,4(r1) a1b4: 44 00 48 00 l.jr r9 a1b8: 9c 21 00 08 l.addi r1,r1,8 3.a. The cpp for this is: AL_API ALvoid AL_APIENTRY alSourcePlay(ALuint source) START_API_FUNC { alSourcePlayv(1, &source); } END_API_FUNC AL_API ALvoid AL_APIENTRY alSourcePlayv(ALsizei n, const ALuint *sources) START_API_FUNC { ContextRef context{GetContextRef()}; if UNLIKELY(!context) return; ... 4. The symbols are from `readelf -s`: 221: 00008ce4 716 FUNC GLOBAL PROTECTED 24 alSourcePausev 222: 00008fb0 36 FUNC GLOBAL PROTECTED 24 alSourcePause 223: 00008fd4 784 FUNC GLOBAL PROTECTED 24 alSourceStopv 224: 000092e4 36 FUNC GLOBAL PROTECTED 24 alSourceStop 225: 00009308 720 FUNC GLOBAL PROTECTED 24 alSourceRewindv 226: 000095d8 36 FUNC GLOBAL PROTECTED 24 alSourceRewind 5. Summary So the issue is that bfd is complaining that because we are doing a PIC link we should not have any R_OR1K_INSN_REL_26 relocations (local calls) to global symbols. Since alSourcePausev / alSourceStopv / alSourcePlayv are global symbols we get this warning. The compiler produced a local jump to the global function, BFD is saying it should be going through the PLT so that runtime linking could be overridden. I looked at the x86 binary and confirm that x86 also uses a local jump, so it could be that the or1k BFD check is being too strict. I will have to read up a bit more about the rules for this to understand what is the right fix. I am CCing Richard who added this check and the binutils list to see if there are any thoughts. -Stafford > > Also I forgot to respond about nios2 bugs. I could help if the bug > > looked the same. But to me it looked different. So I'll hold off for > > now. > > Ok, no problem. Thank you for fixing he OpenRisc ones. > > Best regards > -- > Giulio Benetti > Benetti Engineering sas > > > On Tue, May 25, 2021, 7:10 AM Giulio Benetti > > <giulio.benetti@benettiengineering.com > > <mailto:giulio.benetti@benettiengineering.com>> wrote: > > > > Hi Stafford, > > > > I think I've found another or1k ld bug. Here is the build failure log: > > http://autobuild.buildroot.net/results/ca3/ca3281294392da1a5ea84dbb9cc4c5bfea0c4ccf/build-end.log > > <http://autobuild.buildroot.net/results/ca3/ca3281294392da1a5ea84dbb9cc4c5bfea0c4ccf/build-end.log> > > > > It complains about: > > pc-relative relocation against dynamic symbol > > > > there is an archive of some files(libcommon.a) compiled in the > > beginning > > that gets linked with the rest of .o files. Every file is compiled with > > -fPIC option so this should allow to link a .o with .a but it throws > > that error. > > > > I only see that error in or1k and alpha. Maybe I'm missing something. > > When you have time and if you want, can you help me with that? > > > > If you want to reproduce it it's the same procedure of previous bugs > > but > > you need to specify ca3281294392da1a5ea84dbb9cc4c5bfea0c4ccf to > > br-reproduce-build. > > > > Thanks in advance > > and > > Best regards > > -- Giulio Benetti > > Benetti Engineering sas > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Maybe another or1k bug 2021-06-17 23:41 ` Maybe another or1k bug Stafford Horne @ 2021-07-07 21:06 ` Stafford Horne 2021-07-07 21:25 ` Richard Henderson 0 siblings, 1 reply; 8+ messages in thread From: Stafford Horne @ 2021-07-07 21:06 UTC (permalink / raw) To: Giulio Benetti Cc: Openrisc, GNU Binutils, Richard Henderson, Richard Henderson +CC Richards other account Hi Richard, I Cced this to you twiddle.net account you on this one originally. Do you recall why we added the below check in or1k bfd? It seems to be overly restrictive and causing some issues below. case R_OR1K_INSN_REL_26: if (bfd_link_pic (info) && !SYMBOL_REFERENCES_LOCAL (info, h)) ERROR On Fri, Jun 18, 2021 at 08:41:27AM +0900, Stafford Horne wrote: > On Tue, May 25, 2021 at 01:03:37AM +0200, Giulio Benetti wrote: > > On 5/25/21 12:34 AM, Stafford Horne wrote: > > > I'm cc'ing the list so there is a record, and other experts could come > > > in if they like. > > > > Ah yes, pardon > > > > > Ok, I'll take a look. > > > > > > Thanks, these are always fun for me. > > > > That's great :-) > > So I finally had some time to look at this. I think I understand the issue, but > not sure of the fix yet. Let me explain for the record: > > 1. The error: > > When building openal we get the following: > > /home/buildroot/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: > CMakeFiles/OpenAL.dir/al/source.cpp.o: pc-relative relocation against dynamic > symbol alSourcePausev > /home/buildroot/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: > CMakeFiles/OpenAL.dir/al/source.cpp.o: pc-relative relocation against dynamic > symbol alSourceStopv > /home/buildroot/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: > CMakeFiles/OpenAL.dir/al/source.cpp.o: pc-relative relocation against dynamic > symbol alSourceRewindv > /home/buildroot/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: > CMakeFiles/OpenAL.dir/al/source.cpp.o: pc-relative relocation against dynamic > symbol alSourcePlayv > /home/buildroot/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: > final link failed: bad value > > 2. This is caused by this code in bfd for or1k. > > > case R_OR1K_INSN_REL_26: > case R_OR1K_PCREL_PG21: > case R_OR1K_LO13: > case R_OR1K_SLO13: > /* For a non-shared link, these will reference either the plt > or a .dynbss copy of the symbol. */ > if (bfd_link_pic (info) && !SYMBOL_REFERENCES_LOCAL (info, h)) > { > _bfd_error_handler > (_("%pB: pc-relative relocation against dynamic symbol %s"), > input_bfd, name); > ret_val = false; > bfd_set_error (bfd_error_bad_value); > } > break; > > 3. The code being linked is this from `objdump -dr`: > > 0000a198 <alSourcePlay>: > a198: 9c 21 ff f8 l.addi r1,r1,-8 > a19c: d4 01 18 00 l.sw 0(r1),r3 > a1a0: e0 81 08 04 l.or r4,r1,r1 > a1a4: d4 01 48 04 l.sw 4(r1),r9 > a1a8: 04 00 00 00 l.jal a1a8 <alSourcePlay+0x10> > a1a8: R_OR1K_INSN_REL_26 alSourcePlayv > a1ac: a8 60 00 01 l.ori r3,r0,0x1 > a1b0: 85 21 00 04 l.lwz r9,4(r1) > a1b4: 44 00 48 00 l.jr r9 > a1b8: 9c 21 00 08 l.addi r1,r1,8 > > 3.a. The cpp for this is: > > AL_API ALvoid AL_APIENTRY alSourcePlay(ALuint source) > START_API_FUNC > { alSourcePlayv(1, &source); } > END_API_FUNC > > AL_API ALvoid AL_APIENTRY alSourcePlayv(ALsizei n, const ALuint *sources) > START_API_FUNC > { > ContextRef context{GetContextRef()}; > if UNLIKELY(!context) return; > ... > > 4. The symbols are from `readelf -s`: > > 221: 00008ce4 716 FUNC GLOBAL PROTECTED 24 alSourcePausev > 222: 00008fb0 36 FUNC GLOBAL PROTECTED 24 alSourcePause > 223: 00008fd4 784 FUNC GLOBAL PROTECTED 24 alSourceStopv > 224: 000092e4 36 FUNC GLOBAL PROTECTED 24 alSourceStop > 225: 00009308 720 FUNC GLOBAL PROTECTED 24 alSourceRewindv > 226: 000095d8 36 FUNC GLOBAL PROTECTED 24 alSourceRewind > > > 5. Summary > > So the issue is that bfd is complaining that because we are doing a PIC link > we should not have any R_OR1K_INSN_REL_26 relocations (local calls) to global > symbols. Since alSourcePausev / alSourceStopv / alSourcePlayv are global > symbols we get this warning. > > The compiler produced a local jump to the global function, BFD is saying it > should be going through the PLT so that runtime linking could be overridden. > > I looked at the x86 binary and confirm that x86 also uses a local jump, so it > could be that the or1k BFD check is being too strict. I will have to read up a > bit more about the rules for this to understand what is the right fix. > > I am CCing Richard who added this check and the binutils list to see if there > are any thoughts. > > -Stafford > > > > Also I forgot to respond about nios2 bugs. I could help if the bug > > > looked the same. But to me it looked different. So I'll hold off for > > > now. > > > > Ok, no problem. Thank you for fixing he OpenRisc ones. > > > > Best regards > > -- > > Giulio Benetti > > Benetti Engineering sas > > > > > On Tue, May 25, 2021, 7:10 AM Giulio Benetti > > > <giulio.benetti@benettiengineering.com > > > <mailto:giulio.benetti@benettiengineering.com>> wrote: > > > > > > Hi Stafford, > > > > > > I think I've found another or1k ld bug. Here is the build failure log: > > > http://autobuild.buildroot.net/results/ca3/ca3281294392da1a5ea84dbb9cc4c5bfea0c4ccf/build-end.log > > > <http://autobuild.buildroot.net/results/ca3/ca3281294392da1a5ea84dbb9cc4c5bfea0c4ccf/build-end.log> > > > > > > It complains about: > > > pc-relative relocation against dynamic symbol > > > > > > there is an archive of some files(libcommon.a) compiled in the > > > beginning > > > that gets linked with the rest of .o files. Every file is compiled with > > > -fPIC option so this should allow to link a .o with .a but it throws > > > that error. > > > > > > I only see that error in or1k and alpha. Maybe I'm missing something. > > > When you have time and if you want, can you help me with that? > > > > > > If you want to reproduce it it's the same procedure of previous bugs > > > but > > > you need to specify ca3281294392da1a5ea84dbb9cc4c5bfea0c4ccf to > > > br-reproduce-build. > > > > > > Thanks in advance > > > and > > > Best regards > > > -- Giulio Benetti > > > Benetti Engineering sas > > > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Maybe another or1k bug 2021-07-07 21:06 ` Stafford Horne @ 2021-07-07 21:25 ` Richard Henderson 2021-07-08 21:44 ` Stafford Horne 0 siblings, 1 reply; 8+ messages in thread From: Richard Henderson @ 2021-07-07 21:25 UTC (permalink / raw) To: Stafford Horne, Giulio Benetti; +Cc: Openrisc, GNU Binutils, Richard Henderson On 7/7/21 2:06 PM, Stafford Horne wrote: > +CC Richards other account > > Hi Richard, > > I Cced this to you twiddle.net account you on this one originally. Do you recall > why we added the below check in or1k bfd? It seems to be overly restrictive and > causing some issues below. > > case R_OR1K_INSN_REL_26: > if (bfd_link_pic (info) && !SYMBOL_REFERENCES_LOCAL (info, h)) > ERROR ... >> 4. The symbols are from `readelf -s`: >> >> 221: 00008ce4 716 FUNC GLOBAL PROTECTED 24 alSourcePausev >> 222: 00008fb0 36 FUNC GLOBAL PROTECTED 24 alSourcePause >> 223: 00008fd4 784 FUNC GLOBAL PROTECTED 24 alSourceStopv >> 224: 000092e4 36 FUNC GLOBAL PROTECTED 24 alSourceStop >> 225: 00009308 720 FUNC GLOBAL PROTECTED 24 alSourceRewindv >> 226: 000095d8 36 FUNC GLOBAL PROTECTED 24 alSourceRewind Ah, STV_PROTECTED. Unusual. It looks like this should be SYMBOL_CALLS_LOCAL. The only difference from SYMBOL_REFERENCES_LOCAL is versus protected symbols. r~ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Maybe another or1k bug 2021-07-07 21:25 ` Richard Henderson @ 2021-07-08 21:44 ` Stafford Horne 2021-07-08 22:57 ` Giulio Benetti 2021-07-11 8:36 ` Giulio Benetti 0 siblings, 2 replies; 8+ messages in thread From: Stafford Horne @ 2021-07-08 21:44 UTC (permalink / raw) To: Richard Henderson Cc: Giulio Benetti, Openrisc, GNU Binutils, Richard Henderson On Wed, Jul 07, 2021 at 02:25:39PM -0700, Richard Henderson wrote: > On 7/7/21 2:06 PM, Stafford Horne wrote: > > +CC Richards other account > > > > Hi Richard, > > > > I Cced this to you twiddle.net account you on this one originally. Do you recall > > why we added the below check in or1k bfd? It seems to be overly restrictive and > > causing some issues below. > > > > case R_OR1K_INSN_REL_26: > > if (bfd_link_pic (info) && !SYMBOL_REFERENCES_LOCAL (info, h)) > > ERROR > ... > > > 4. The symbols are from `readelf -s`: > > > > > > 221: 00008ce4 716 FUNC GLOBAL PROTECTED 24 alSourcePausev > > > 222: 00008fb0 36 FUNC GLOBAL PROTECTED 24 alSourcePause > > > 223: 00008fd4 784 FUNC GLOBAL PROTECTED 24 alSourceStopv > > > 224: 000092e4 36 FUNC GLOBAL PROTECTED 24 alSourceStop > > > 225: 00009308 720 FUNC GLOBAL PROTECTED 24 alSourceRewindv > > > 226: 000095d8 36 FUNC GLOBAL PROTECTED 24 alSourceRewind > > Ah, STV_PROTECTED. Unusual. > > It looks like this should be SYMBOL_CALLS_LOCAL. The only difference from > SYMBOL_REFERENCES_LOCAL is versus protected symbols. Thanks Richard. I will post a patch for this in a few days. Or, maybe Giulio can do it if he has time. -Stafford ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Maybe another or1k bug 2021-07-08 21:44 ` Stafford Horne @ 2021-07-08 22:57 ` Giulio Benetti 2021-07-11 8:36 ` Giulio Benetti 1 sibling, 0 replies; 8+ messages in thread From: Giulio Benetti @ 2021-07-08 22:57 UTC (permalink / raw) To: Stafford Horne, Richard Henderson Cc: Openrisc, GNU Binutils, Richard Henderson Hi Stafford, On 7/8/21 11:44 PM, Stafford Horne wrote: > On Wed, Jul 07, 2021 at 02:25:39PM -0700, Richard Henderson wrote: >> On 7/7/21 2:06 PM, Stafford Horne wrote: >>> +CC Richards other account >>> >>> Hi Richard, >>> >>> I Cced this to you twiddle.net account you on this one originally. Do you recall >>> why we added the below check in or1k bfd? It seems to be overly restrictive and >>> causing some issues below. >>> >>> case R_OR1K_INSN_REL_26: >>> if (bfd_link_pic (info) && !SYMBOL_REFERENCES_LOCAL (info, h)) >>> ERROR >> ... >>>> 4. The symbols are from `readelf -s`: >>>> >>>> 221: 00008ce4 716 FUNC GLOBAL PROTECTED 24 alSourcePausev >>>> 222: 00008fb0 36 FUNC GLOBAL PROTECTED 24 alSourcePause >>>> 223: 00008fd4 784 FUNC GLOBAL PROTECTED 24 alSourceStopv >>>> 224: 000092e4 36 FUNC GLOBAL PROTECTED 24 alSourceStop >>>> 225: 00009308 720 FUNC GLOBAL PROTECTED 24 alSourceRewindv >>>> 226: 000095d8 36 FUNC GLOBAL PROTECTED 24 alSourceRewind >> >> Ah, STV_PROTECTED. Unusual. >> >> It looks like this should be SYMBOL_CALLS_LOCAL. The only difference from >> SYMBOL_REFERENCES_LOCAL is versus protected symbols. > > Thanks Richard. > > I will post a patch for this in a few days. Or, maybe Giulio can do it if he > has time. Yes, I can give a try. I've never patched binutils but I can try to. I'll let you know the result soon. Thank you and Best regards -- Giulio Benetti Benetti Engineering sas ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Maybe another or1k bug 2021-07-08 21:44 ` Stafford Horne 2021-07-08 22:57 ` Giulio Benetti @ 2021-07-11 8:36 ` Giulio Benetti 2021-07-11 13:24 ` Richard Henderson 1 sibling, 1 reply; 8+ messages in thread From: Giulio Benetti @ 2021-07-11 8:36 UTC (permalink / raw) To: Stafford Horne Cc: Richard Henderson, Openrisc, GNU Binutils, Richard Henderson Hi Stafford, All, > Il giorno 8 lug 2021, alle ore 23:44, Stafford Horne <shorne@gmail.com> ha scritto: > > On Wed, Jul 07, 2021 at 02:25:39PM -0700, Richard Henderson wrote: >>> On 7/7/21 2:06 PM, Stafford Horne wrote: >>> +CC Richards other account >>> >>> Hi Richard, >>> >>> I Cced this to you twiddle.net account you on this one originally. Do you recall >>> why we added the below check in or1k bfd? It seems to be overly restrictive and >>> causing some issues below. >>> >>> case R_OR1K_INSN_REL_26: >>> if (bfd_link_pic (info) && !SYMBOL_REFERENCES_LOCAL (info, h)) >>> ERROR >> ... >>>> 4. The symbols are from `readelf -s`: >>>> >>>> 221: 00008ce4 716 FUNC GLOBAL PROTECTED 24 alSourcePausev >>>> 222: 00008fb0 36 FUNC GLOBAL PROTECTED 24 alSourcePause >>>> 223: 00008fd4 784 FUNC GLOBAL PROTECTED 24 alSourceStopv >>>> 224: 000092e4 36 FUNC GLOBAL PROTECTED 24 alSourceStop >>>> 225: 00009308 720 FUNC GLOBAL PROTECTED 24 alSourceRewindv >>>> 226: 000095d8 36 FUNC GLOBAL PROTECTED 24 alSourceRewind >> >> Ah, STV_PROTECTED. Unusual. >> >> It looks like this should be SYMBOL_CALLS_LOCAL. The only difference from >> SYMBOL_REFERENCES_LOCAL is versus protected symbols. > > Thanks Richard. > > I will post a patch for this in a few days. Or, maybe Giulio can do it if he > has time. Substituting SYMBOL_REFERENCES_LOCAL with SYMBOL_CALLS_LOCAL fixes the problem. Only one thing, is it valid for every case in that switch or must it be only for R_OR1K_INSN_REL_26? I’ve built and entire buildroot system with all cases with that new condition and it builds successfully. Please let me know so I can send a patch for this. Thank you and Best regards Giulio Benetti ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Maybe another or1k bug 2021-07-11 8:36 ` Giulio Benetti @ 2021-07-11 13:24 ` Richard Henderson 2021-07-11 13:41 ` Giulio Benetti 0 siblings, 1 reply; 8+ messages in thread From: Richard Henderson @ 2021-07-11 13:24 UTC (permalink / raw) To: Giulio Benetti, Stafford Horne; +Cc: Openrisc, GNU Binutils, Richard Henderson On 7/11/21 1:36 AM, Giulio Benetti wrote: > Substituting SYMBOL_REFERENCES_LOCAL with SYMBOL_CALLS_LOCAL fixes the problem. > Only one thing, is it valid for every case in that switch or must it be only for R_OR1K_INSN_REL_26? Only for INSN_REL_26. r~ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Maybe another or1k bug 2021-07-11 13:24 ` Richard Henderson @ 2021-07-11 13:41 ` Giulio Benetti 0 siblings, 0 replies; 8+ messages in thread From: Giulio Benetti @ 2021-07-11 13:41 UTC (permalink / raw) To: Richard Henderson Cc: Stafford Horne, Openrisc, GNU Binutils, Richard Henderson > Il giorno 11 lug 2021, alle ore 15:24, Richard Henderson <richard.henderson@linaro.org> ha scritto: > > On 7/11/21 1:36 AM, Giulio Benetti wrote: >> Substituting SYMBOL_REFERENCES_LOCAL with SYMBOL_CALLS_LOCAL fixes the problem. >> Only one thing, is it valid for every case in that switch or must it be only for R_OR1K_INSN_REL_26? > > Only for INSN_REL_26. Perfect, I’m going to modify and submit soon. Thank you Giulio ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-07-11 13:41 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <dbcce22d-b288-2451-4a8d-681f802c6f49@benettiengineering.com>
[not found] ` <CAAfxs77Y1qOzex=Bkn5c_4Zxt6nzZP2cpG6qJ85eXnrAm18FgA@mail.gmail.com>
[not found] ` <6bc67759-18c2-bca5-bdb2-c637e873b8ab@benettiengineering.com>
2021-06-17 23:41 ` Maybe another or1k bug Stafford Horne
2021-07-07 21:06 ` Stafford Horne
2021-07-07 21:25 ` Richard Henderson
2021-07-08 21:44 ` Stafford Horne
2021-07-08 22:57 ` Giulio Benetti
2021-07-11 8:36 ` Giulio Benetti
2021-07-11 13:24 ` Richard Henderson
2021-07-11 13:41 ` Giulio Benetti
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).