On Mon, Nov 28, 2022 at 5:53 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > On 11/28/22 06:59, Joakim Nohlgård wrote: > > The check for HAVE_LD_RO_RW_SECTION_MIXING fails on targets where ld > > does not support shared objects, even though the answer to the test > > should be 'read-write'. One such target is riscv64-unknown-elf. Failing > > this test results in a libgcc crtbegin.o which has a writable .eh_frame > > section leading to the default linker scripts placing the .eh_frame > > section in a writable memory segment, or a linker warning about writable > > sections in a read-only segment when using ld scripts that place > > .eh_frame unconditionally in ROM. > > > > gcc/ChangeLog: > > > > * configure: Regenerate. > > * configure.ac: Use ld -r in the check for > > HAVE_LD_RO_RW_SECTION_MIXING > > I'm not sure that simply replacing -shared with -r is the right fix > here. ISTM that if the -shared tests fails, then we can/should try the > -r variant. Am I missing something here? > I have posted a v2 patch. The new patch tries ld -shared first and falling back to ld -r if that fails.
I believe the original reason for using ld -shared in the first place was that it was a convenient way to let the conftest1,2,3 code be as simple as possible. Using ld without any flags would require a program entry point (_start) at the very minimum. Using ld -r has the same effect as the ld -shared link in this case, where we just want to merge sections with the same name from different input files and check what section flags were propagated to the output file.