Re: [GOLD][PATCH] Fix -z relro bugs

[Ian Lance Taylor <iant at google dot com>]

"Doug Kwan (éæå)" <dougkwan@google.com> writes:

>    This patch fixes two problems related to the -z relro option.  The
> first one is that .init_array, .fini_array and .preinit_array are not
> handle properly in Layout::make_output_seciton.  The function only
> force the relro flag if section type if SHT_PROGBITS.  The second
> problem is that the ARM backend ignores the -z now option.  This patch
> fixes this problem and also places the .got section at the RELRO
> boundary.  This is tested on both ARM and x86_64.
>
> -Doug
>
>
> 2012-03-15  Doug Kwan  <dougkwan@google.com>
>
>         * arm.cc (Target_arm::got_section): Make .got section read-only
>         if -z now is given. Also place .got section at RELRO boundary.
>         * layout.cc (Layout::make_output_section): Fix a bug that causes
>         .init_array, .fini_array and .preinit_array to be not included
>         in the RELRO segment when -z now is given.


(Please send to binutils@sourceware.org, not
binutils@sources.redhat.com.  Thanks.)

Coincidentally somebody reported the layout.cc change thing as a PR and
I fixed it this morning.

> +      // When using -z now, we can treat .got as a relro section.
> +      // Without -z now, it is modified after program startup by lazy
> +      // PLT relocations.
> +      bool is_got_relro = parameters->options().now();
> +      Output_section_order got_order = (is_got_relro
> +					? ORDER_RELRO_LAST
> +					: ORDER_NON_RELRO_FIRST);

As far as I can see this hsould be ORDER_DATA rather than
ORDER_NON_RELRO_FIRST.  The x86 support uses ORDER_NON_RELRO_FIRST
because it calls layout->increase_relro.  If you don't use that, you
might as well use ORDER_DATA.  Unless there is some other reason that
the section should be first, but what?

This patch is OK using ORDER_DATA, or with ORDER_NON_RELRO_FIRST if
there is a reason for it.

Thanks.

Ian