From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
To: Baoquan He <bhe@redhat.com>
Cc: Dave Young <dyoung@redhat.com>,
kexec@lists.infradead.org,
"Eric W. Biederman" <ebiederm@xmission.com>,
Michael Ellerman <mpe@ellerman.id.au>,
linuxppc-dev@lists.ozlabs.org, Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [RFC] kexec_file: Add support for purgatory built as PIE
Date: Fri, 04 Nov 2016 13:43:55 -0200 [thread overview]
Message-ID: <1558014.uilYosVS7M@morokweng> (raw)
In-Reply-To: <20161104073840.GD4314@x1>
Hello Baoquan,
Am Freitag, 4. November 2016, 15:38:40 BRST schrieb Baoquan He:
> On 11/02/16 at 04:00am, Thiago Jung Bauermann wrote:
> > Hello,
> >
> > The kexec_file code currently builds the purgatory as a partially linked
> > object (using ld -r). Is there a particular reason to use that instead of
> > a position independent executable (PIE)?
>
> It's taken as "-r", relocatable in user space kexec-tools too originally.
> I think Vivek just keeps it the same when moving into kernel.
Ok. If that's the only reason then PIE is better suited at least for powerpc.
> > I found a discussion from 2013 in the archives but from what I understood
> > it was about the purgatory as a separate object vs having it linked into
> > the kernel, which is different from what I'm asking:
> >
> > http://lists.infradead.org/pipermail/kexec/2013-December/010535.html
> >
> > Here is my motivation for this question:
> > On ppc64 purgatory.ro has 12 relocation types when built as a partially
> >
> > linked object. This makes arch_kexec_apply_relocations_add duplicate a lot
> > of code with module_64.c:apply_relocate_add to implement these
> > relocations. The alternative is to do some refactoring so that both
> > functions can share the implementation of the relocations. This is done
> > in patches 5 and 6 of the
> > kexec_file_load implementation for powerpc:
> In user space kexec-tools utility, you also got this problem?
Yes, kexec-tools' purgatory.ro has 10 relocation types instead of 12 (I don't
know why), but that's still a lot.
> > @@ -942,7 +1085,13 @@ static Elf_Sym *kexec_purgatory_find_symbol(struct
> > purgatory_info *pi,>
> > /* Go through symbols for a match */
> > for (k = 0; k < sechdrs[i].sh_size/sizeof(Elf_Sym); k++) {
> >
> > - if (ELF_ST_BIND(syms[k].st_info) != STB_GLOBAL)
> > + /*
> > + * FIXME: See if we can or should export the .TOC.
> > + * symbol as global instead of searching local symbols
> > + * here.
> > + */
> > + if (ELF_ST_BIND(syms[k].st_info) != STB_GLOBAL &&
> > + ELF_ST_BIND(syms[k].st_info) != STB_LOCAL)
> >
> > continue;
> >
> > if (strcmp(strtab + syms[k].st_name, name) != 0)
> >
I don't need the change above anymore. I found a way to obtain the TOC pointer
without looking for the .TOC. symbol.
--
Thiago Jung Bauermann
IBM Linux Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
To: Baoquan He <bhe@redhat.com>
Cc: kexec@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
"Eric W. Biederman" <ebiederm@xmission.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Dave Young <dyoung@redhat.com>, Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [RFC] kexec_file: Add support for purgatory built as PIE
Date: Fri, 04 Nov 2016 13:43:55 -0200 [thread overview]
Message-ID: <1558014.uilYosVS7M@morokweng> (raw)
In-Reply-To: <20161104073840.GD4314@x1>
Hello Baoquan,
Am Freitag, 4. November 2016, 15:38:40 BRST schrieb Baoquan He:
> On 11/02/16 at 04:00am, Thiago Jung Bauermann wrote:
> > Hello,
> >
> > The kexec_file code currently builds the purgatory as a partially linked
> > object (using ld -r). Is there a particular reason to use that instead of
> > a position independent executable (PIE)?
>
> It's taken as "-r", relocatable in user space kexec-tools too originally.
> I think Vivek just keeps it the same when moving into kernel.
Ok. If that's the only reason then PIE is better suited at least for powerpc.
> > I found a discussion from 2013 in the archives but from what I understood
> > it was about the purgatory as a separate object vs having it linked into
> > the kernel, which is different from what I'm asking:
> >
> > http://lists.infradead.org/pipermail/kexec/2013-December/010535.html
> >
> > Here is my motivation for this question:
> > On ppc64 purgatory.ro has 12 relocation types when built as a partially
> >
> > linked object. This makes arch_kexec_apply_relocations_add duplicate a lot
> > of code with module_64.c:apply_relocate_add to implement these
> > relocations. The alternative is to do some refactoring so that both
> > functions can share the implementation of the relocations. This is done
> > in patches 5 and 6 of the
> > kexec_file_load implementation for powerpc:
> In user space kexec-tools utility, you also got this problem?
Yes, kexec-tools' purgatory.ro has 10 relocation types instead of 12 (I don't
know why), but that's still a lot.
> > @@ -942,7 +1085,13 @@ static Elf_Sym *kexec_purgatory_find_symbol(struct
> > purgatory_info *pi,>
> > /* Go through symbols for a match */
> > for (k = 0; k < sechdrs[i].sh_size/sizeof(Elf_Sym); k++) {
> >
> > - if (ELF_ST_BIND(syms[k].st_info) != STB_GLOBAL)
> > + /*
> > + * FIXME: See if we can or should export the .TOC.
> > + * symbol as global instead of searching local symbols
> > + * here.
> > + */
> > + if (ELF_ST_BIND(syms[k].st_info) != STB_GLOBAL &&
> > + ELF_ST_BIND(syms[k].st_info) != STB_LOCAL)
> >
> > continue;
> >
> > if (strcmp(strtab + syms[k].st_name, name) != 0)
> >
I don't need the change above anymore. I found a way to obtain the TOC pointer
without looking for the .TOC. symbol.
--
Thiago Jung Bauermann
IBM Linux Technology Center
next prev parent reply other threads:[~2016-11-04 15:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-02 6:00 [RFC] kexec_file: Add support for purgatory built as PIE Thiago Jung Bauermann
2016-11-02 6:00 ` Thiago Jung Bauermann
2016-11-04 7:38 ` Baoquan He
2016-11-04 7:38 ` Baoquan He
2016-11-04 15:13 ` Eric W. Biederman
2016-11-04 15:13 ` Eric W. Biederman
2016-11-04 19:19 ` Thiago Jung Bauermann
2016-11-04 19:19 ` Thiago Jung Bauermann
2016-11-04 15:43 ` Thiago Jung Bauermann [this message]
2016-11-04 15:43 ` Thiago Jung Bauermann
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=1558014.uilYosVS7M@morokweng \
--to=bauerman@linux.vnet.ibm.com \
--cc=bhe@redhat.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=vgoyal@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.