[PATCH v3 2/2] Default to --with-default-link=no (bug 25812)

[Fangrui Song]

On 2022-04-29, Florian Weimer wrote:
>* Fangrui Song:
>
>>>How does lld place sections without a linker script?  Purely based on
>>>names?
>>
>> It entirely uses code to describe the built-in rules like gold, while
>> GNU ld uses an internal linker script plus built-in code.
>> (some rules cannot be described by the linker script language and needs
>> code anyway).
>
>How can we make sure that certain sections are covered by RELRO, and
>still get start/stop symbols for them?

About __start_/__stop_:
__start_/__stop_ symbols are special. They don't need to be mentioned in a
linker script to take effects for lld and modern GNU ld. I haven't checked
whether there is an ancient GNU ld which requires symbol assignments when the
output section description is specified.

About RELRO:
It seems that there is no section name convention to make a section
RELRO.  Having a SECTIONS command with DATA_SEGMENT_ALIGN /
DATA_SEGMENT_RELRO_END can specify all RELRO sections. I do not know a
simpler approach than postprocessing ld.bfd --verbose output.

To make GNU ld work, the following linker script is sufficient:

   SECTIONS {
            __libc_subfreeres : { *(__libc_subfreeres) }
            __libc_atexit : { *(__libc_atexit) }
            __libc_IO_vtables : { *(__libc_IO_vtables) }
   } INSERT BEFORE .data.rel.ro;

This script does not work with ld.lld right now because there is an
`error: section ... is not contiguous with other relro sections` from
https://reviews.llvm.org/D40359 . I need to think whether the diagnostic
can be suppressed in some cases.

>>>> Besides, the position of .hash in --with-default-link=no seems weird.
>>>> 71213dc2589554dc8f8061e9b04e80c55d098b6a (2006-09) moved it to the end
>>>> of the RO segment.
>>>
>>>I think it's odd that we have an old-style hash table at all.  Do we
>>>really need it?  All tools should have migrated by now.
>>
>> We can remove .hash for non-mips architectures.
>
>We need the support in glibc for most architectures in the dynamic
>linker, but we don't have to build glibc with the legacy hash tables.

Agree

>> (I am a bit sad .MIPS.xhash support went in, but thankfully it doesn't take
>> too much code.  The translation table could be solved in a better way. I
>> suspect the whole thing is unnecessary with RELR.)
>
>Huh?  Aren't they unrelated?
>

`DT_MIPS_LOCAL_GOTNO` and `DT_MIPS_SYMTABNO-DT_MIPS_GOTSYM` can be
defined in a way that there is no special handling. Then there will be no
requirement on the .dynsym ordering. Then the regular DT_GNU_HASH can be
used, and DT_MIPS_XHASH will be unneeded.

`DT_MIPS_LOCAL_GOTNO` optimizes on top of relative relocations but with RELR
the additional benefit is very low.

>Thanks,
>Florian
>