[PATCH v3 2/4] ld: Document mixing IR and non-IR objects for -r

[H.J. Lu]

On Sun, Jan 12, 2025 at 5:40 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Sun, Jan 12, 2025, 5:16 PM Sam James <sam@gentoo.org> wrote:
>>
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>
>> > On Sun, Jan 12, 2025 at 5:03 PM Sam James <sam@gentoo.org> wrote:
>> >>
>> >> "H.J. Lu" <hjl.tools@gmail.com> writes:
>> >>
>> >> > On Sun, Jan 12, 2025 at 4:16 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>> >> >>
>> >> >> On Jan 12 2025, H.J. Lu wrote:
>> >> >>
>> >> >> > +On ELF platforms, when the relocatable output contains both IR and
>> >> >> > +non-IR contents, a .gnu_object_only section will be created to contain
>> >> >>
>> >> >> Whatis IR?
>> >> >>
>> >> >
>> >> > How about this?
>> >> >
>> >> > On ELF platforms, when the relocatable output contains both contents
>> >> > which require link-time optimization (LTO) and contents which don't
>> >> > require LTO, a .gnu_object_only section will be created to contain a
>> >> > relocatable object file, as if @samp{-r} is applied to all relocatable
>> >> > inputs which don't require LTO.  When processing a relocatable input
>> >> > with a .gnu_object_only section, the linker will extract the
>> >> > .gnu_object_only section as a separate input.
>> >>
>> >> That reads well to me. Maybe we should include a reference to
>> >> -ffat-lto-objects.
>> >
>> > I am trying to avoid compiler options in the linker manual.
>>
>> OK, fair enough. Can we compromise on including it in the commit
>> message, to help grepping/searching?
>
>
> Will do.

 -ffat-lto-objects is unrelated to this since linkers can ignore either
LTO contents or no-LTO contents without causing any linker error
since they provide the same set of symbol definitions.

> Thanks.
>
>>
>>


-- 
H.J.