Re: [PATCH] gcc: Use ld -r when checking for HAVE_LD_RO_RW_SECTION_MIXING

["Joakim Nohlgård" <joakim@nohlgard.se>]

On Mon, Nov 28, 2022 at 5:53 PM Jeff Law <jeffreyalaw@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.