public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Fangrui Song <maskray@google.com>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	linux-mips@vger.kernel.org, clang-built-linux@googlegroups.com,
	Nathan Chancellor <natechancellor@gmail.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Borislav Petkov <bp@suse.de>, Kees Cook <keescook@chromium.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] MIPS: Truncate link address into 32bit for 32bit kernel
Date: Mon, 13 Apr 2020 08:34:53 -0700	[thread overview]
Message-ID: <20200413153453.zi4jvu3c4ul23e23@google.com> (raw)
In-Reply-To: <20200413153205.4ee52239@flygoat-x1e>

On 2020-04-13, Jiaxun Yang wrote:
>On Mon, 13 Apr 2020 07:59:29 +0100 (BST)
>"Maciej W. Rozycki" <macro@linux-mips.org> wrote:
>
>> On Mon, 13 Apr 2020, Jiaxun Yang wrote:
>>
>> > LLD failed to link vmlinux with 64bit load address for 32bit ELF
>> > while bfd will strip 64bit address into 32bit silently.
>> > To fix LLD build, we should truncate load address provided by
>> > platform into 32bit for 32bit kernel.
>>
>> Reviewed-by: Maciej W. Rozycki <macro@linux-mips.org>
>>
>> > diff --git a/arch/mips/kernel/vmlinux.lds.S
>> > b/arch/mips/kernel/vmlinux.lds.S index a5f00ec73ea6..5226cd8e4bee
>> > 100644 --- a/arch/mips/kernel/vmlinux.lds.S
>> > +++ b/arch/mips/kernel/vmlinux.lds.S
>> > @@ -55,7 +55,7 @@ SECTIONS
>> >  	/* . = 0xa800000000300000; */
>> >  	. = 0xffffffff80300000;
>> >  #endif
>> > -	. = VMLINUX_LOAD_ADDRESS;
>> > +	. = VMLINUX_LINK_ADDRESS;
>>
>>  The CONFIG_BOOT_ELF64 cruft right above it looks interesting to me,
>> never have ever been used.  We have had the current arrangement since:
>
>It confused me either.
>It's only used by SGI so probably it's time to rename it as
>BOOT_SEG_ELF64.
>
>Wish someone could clarify what is it.
>
>Thanks.

Agreed that -Ttext in

arch/mips/boot/compressed/Makefile
100:      cmd_zld = $(LD) $(KBUILD_LDFLAGS) -Ttext $(VMLINUZ_LOAD_ADDRESS) -T $< $(vmlinuzobjs-y) -o $@

and a few other places are brittle. They need to be replaced with Output Section Address:
(https://sourceware.org/binutils/docs/ld/Output-Section-Address.html
https://github.com/llvm/llvm-project/blob/master/lld/docs/ELF/linker_script.rst#output-section-address)

-Ttext changes the address of .text . This can lead to the change of the
address of the text segment (RX), but this is not guaranteed (many
sections can be placed before .text and they are not affected).
See https://reviews.llvm.org/D70468 "[ELF] Error if -Ttext-segment is specified"


Reviewed-by: Fangrui Song <maskray@google.com>

>>
>> commit 923ec3d20eef9e36456868b590873ce39f17fe71
>> Author: Ralf Baechle <ralf@linux-mips.org>
>> Date:   Wed Nov 6 22:16:38 2002 +0000
>>
>>     Define load address in linker script instead of relying on the
>>     deprecated and notoriously unreliable option -Ttext.
>>
>> and previously `-Ttext' was used with this script anyway, though not
>> very long, as the script was entirely ignored until:
>>
>> commit 7a782968041ffc4c2d89816238e2f8ea5cceddba
>> Author: Ralf Baechle <ralf@linux-mips.org>
>> Date:   Thu Oct 31 23:54:21 2002 +0000
>>
>>     Merge with Linux 2.5.36.
>>
>>   Maciej
>
>--
>Jiaxun Yang

  reply	other threads:[~2020-04-13 15:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13  6:26 [PATCH v4] MIPS: Truncate link address into 32bit for 32bit kernel Jiaxun Yang
2020-04-13  6:59 ` Maciej W. Rozycki
2020-04-13  7:32   ` Jiaxun Yang
2020-04-13 15:34     ` Fangrui Song [this message]
2020-04-13 20:08       ` Maciej W. Rozycki
2020-04-13 20:06     ` Maciej W. Rozycki
2020-04-13 16:25 ` Kees Cook
2020-04-13 18:52 ` Nathan Chancellor
2020-04-22 14:32 ` [PATCH v5] " Jiaxun Yang
2020-04-22 22:16   ` Nathan Chancellor
2020-04-23  0:10   ` Maciej W. Rozycki
2020-04-23  5:42     ` Jiaxun Yang
2020-04-24 12:22       ` Maciej W. Rozycki
2020-05-04 15:46         ` Thomas Bogendoerfer
2020-05-04 16:09           ` Jiaxun Yang
2020-05-04 16:56             ` Thomas Bogendoerfer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200413153453.zi4jvu3c4ul23e23@google.com \
    --to=maskray@google.com \
    --cc=bp@suse.de \
    --cc=clang-built-linux@googlegroups.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jiaxun.yang@flygoat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=natechancellor@gmail.com \
    --cc=tsbogend@alpha.franken.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox