On 2019-11-27, Alex Bennée wrote: > >Fangrui Song writes: > >> For lld, --image-base is the preferred way to set the base address. >> lld does not actually implement -Ttext-segment, but treats it as an alias for >> -Ttext. -Ttext-segment=0x60000000 combined with --no-rosegment can >> create a 1.6GB executable. >> >> Fix the problem by using --image-base for lld. GNU ld and gold will >> still get -Ttext-segment. Also delete the ld --verbose fallback introduced >> in 2013, which is no longer relevant or correct (the default linker >> script has changed). >> >> Signed-off-by: Fangrui Song > >This patch no longer applies cleanly to configure so I couldn't test it. configure was touched twice last week, but git still works. Anyway, I am uploading a new patch without In-Reply-To. >> --- >> configure | 33 ++++++++++++--------------------- >> 1 file changed, 12 insertions(+), 21 deletions(-) >> >> diff --git a/configure b/configure >> index 6099be1d84..2d45af0d09 100755 >> --- a/configure >> +++ b/configure >> @@ -6336,43 +6336,34 @@ fi >> >> # Probe for the need for relocating the user-only binary. >> if ( [ "$linux_user" = yes ] || [ "$bsd_user" = yes ] ) && [ "$pie" = no ]; then >> - textseg_addr= >> + image_base= >> case "$cpu" in >> arm | i386 | ppc* | s390* | sparc* | x86_64 | x32) >> - # ??? Rationale for choosing this address >> - textseg_addr=0x60000000 >> + # An arbitrary address that makes it unlikely to collide with user >> + # programs. >> + image_base=0x60000000 > >The comment probably belongs up above when we define the empty variable >unless it really is specifically about these targets. Moved the comment. >Renaming textseg_addr seems like unnecessary churn for this patch. Renaming is necessary. "Text segment" is no more an appropriate term even with GNU ld due to the prevalence of -z separate-code (--enable-separate-code is the default on Linux x86-64 in recent binutils releases). There is a PF_R PT_LOAD before PF_R|PF_X PT_LOAD (text segment). One may argue that we can name the two PT_LOAD collectively as "text segment but I don't think that is appropriate. > >> ;; >> mips) >> # A 256M aligned address, high in the address space, with enough >> # room for the code_gen_buffer above it before the stack. >> - textseg_addr=0x60000000 >> + image_base=0x60000000 >> ;; >> esac >> - if [ -n "$textseg_addr" ]; then >> + if [ -n "$image_base" ]; then >> cat > $TMPC <> int main(void) { return 0; } >> EOF >> - textseg_ldflags="-Wl,-Ttext-segment=$textseg_addr" >> - if ! compile_prog "" "$textseg_ldflags"; then >> - # In case ld does not support -Ttext-segment, edit the default linker >> - # script via sed to set the .text start addr. This is needed on FreeBSD >> - # at least. >> - if ! $ld --verbose >/dev/null 2>&1; then >> + image_base_ldflags="-Wl,--image-base=$image_base" >> + if ! compile_prog "" "$image_base_ldflags"; then >> + image_base_ldflags="-Wl,-Ttext-segment=$image_base" >> + if ! compile_prog "" "$image_base_ldflags"; then >> error_exit \ >> "We need to link the QEMU user mode binaries at a" \ >> "specific text address. Unfortunately your linker" \ >> - "doesn't support either the -Ttext-segment option or" \ >> - "printing the default linker script with --verbose." \ >> + "supports neither --image-base nor -Ttext-segment. " \ >> "If you don't want the user mode binaries, pass the" \ >> "--disable-user option to configure." >> fi >> - >> - $ld --verbose | sed \ >> - -e '1,/==================================================/d' \ >> - -e '/==================================================/,$d' \ >> - -e "s/[.] = [0-9a-fx]* [+] SIZEOF_HEADERS/. = $textseg_addr + SIZEOF_HEADERS/" \ >> - -e "s/__executable_start = [0-9a-fx]*/__executable_start = $textseg_addr/" > config-host.ld >> - textseg_ldflags="-Wl,-T../config-host.ld" >> fi >> fi >> fi >> @@ -7945,7 +7936,7 @@ if test "$gprof" = "yes" ; then >> fi >> >> if test "$target_linux_user" = "yes" || test "$target_bsd_user" = "yes" ; then >> - ldflags="$ldflags $textseg_ldflags" >> + ldflags="$ldflags $image_base_ldflags" >> fi >> >> # Newer kernels on s390 check for an S390_PGSTE program header and (I'm not subscribed to the list, so please CC me. I made this reply by downloading https://lists.gnu.org/archive/mbox/qemu-devel/2019-11)