Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Arvind Sankar <nivedita@alum.mit.edu>
Date:   Mon, 24 Feb 2020 17:43:44 -0500
To:     Fangrui Song <maskray@google.com>
Cc:     Arvind Sankar <nivedita@alum.mit.edu>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Michael Matz <matz@suse.de>, Borislav Petkov <bp@alien8.de>,
        Nathan Chancellor <natechancellor@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        clang-built-linux <clang-built-linux@googlegroups.com>,
        Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH 2/2] x86/boot/compressed: Remove unnecessary sections
 from bzImage
Message-ID: <20200224224343.GA572699@rani.riverdale.lan>
References: <20200222070218.GA27571@ubuntu-m2-xlarge-x86>
 <20200222072144.asqaxlv364s6ezbv@google.com>
 <20200222074254.GB11284@zn.tnic>
 <20200222162225.GA3326744@rani.riverdale.lan>
 <CAKwvOdnvMS21s9gLp5nUpDAOu=c7-iWYuKTeFUq+PMhsJOKUgw@mail.gmail.com>
 <alpine.LSU.2.21.2002241319150.12812@wotan.suse.de>
 <CAKwvOd=nCAyXtng1N-fvNYa=-NGD0yu+Rm6io9F1gs0FieatwA@mail.gmail.com>
 <20200224212828.xvxl3mklpvlrdtiw@google.com>
 <20200224214845.GC409112@rani.riverdale.lan>
 <20200224221703.eqql5hrx4ccngwa5@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20200224221703.eqql5hrx4ccngwa5@google.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Feb 24, 2020 at 02:17:03PM -0800, Fangrui Song wrote:
> On 2020-02-24, Arvind Sankar wrote:
> >On Mon, Feb 24, 2020 at 01:28:28PM -0800, Fangrui Song wrote:
> >> Hi Michael, please see my other reply on this thread: https://lkml.org/lkml/2020/2/24/47
> >>
> >> Synthesized sections can be matched as well. For example, SECTIONS { .pltfoo : { *(.plt) }} can rename the output section .plt to .pltfoo
> >> It seems that in GNU ld, the synthesized section is associated with the
> >> original object file, so it can be written as:
> >>
> >>    SECTIONS { .pltfoo : { a.o(.plt) }}
> >>
> >> In lld, you need a wildcard to match the synthesized section *(.plt)
> >>
> >> .rela.dyn is another example.
> >>
> >
> >With the BFD toolchain, file matching doesn't actually seem to work at
> >least for .rela.dyn. I've tried playing around with it in the past and
> >if you try to use file-matching to capture relocations from a particular
> >input file, it just doesn't work sensibly.
> 
> I think most things are working in GNU ld...
> 
> /* a.x */
> SECTIONS {
>    .rela.pltfoo : { a.o(.rela.plt) }  /* *(.rela.plt) with lld */
>    .rela.dynfoo : { a.o(.rela.data) } /* *(.rela.dyn) with lld */
> }

The file matching doesn't do anything sensible. If you split your .data
section out into b.s, and update the linker script so it filters for
b.o(.rela.data), .rela.dynfoo doesn't get created, instead the default
.rela.dyn will contains the .data section relocation. If you keep the
filter as a.o(.rela.data), you get .rela.dynfoo, even though a.o doesn't
actually contain any .rela.data section any more.

> 
> % cat <<e > a.s
>   .globl foo
>   foo:
>     call bar
>   .data
>   .quad quz
> e
> % as a.s -o a.o
> % ld.bfd -T a.x a.o -shared -o a.so