From: Joe Lawrence <joe.lawrence@redhat.com>
To: Joao Moreira <jmoreira@suse.de>, Miroslav Benes <mbenes@suse.cz>
Cc: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
linux-kbuild@vger.kernel.org, Jessica Yu <jeyu@kernel.org>,
Jiri Kosina <jikos@kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Michael Matz <matz@suse.de>, Nicolai Stange <nstange@suse.de>,
Petr Mladek <pmladek@suse.com>
Subject: Re: [PATCH v3 0/9] klp-convert livepatch build tooling
Date: Wed, 24 Apr 2019 15:31:21 -0400 [thread overview]
Message-ID: <97990f04-9c4c-17ad-901c-5285901d5a7f@redhat.com> (raw)
In-Reply-To: <bcedf943-6c94-5d23-a637-4f29daf21eda@suse.de>
On 4/24/19 3:13 PM, Joao Moreira wrote:
>>> Future Work
>>> -----------
>>>
>>> I don't see an easy way to support multiple homonym <object, name>
>>> symbols with unique <position> values in the current livepatch module
>>> Elf format. The only solutions that come to mind right now include
>>> renaming homonym symbols somehow to retain the relocation->symbol
>>> relationship when separate object files are combined. Perhaps an
>>> intermediate linker step could make annotated symbols unique in some way
>>> to achieve this. /thinking out loud
>> I'd set this aside for now and we can return to it later. I think it could
>> be quite rare in practice.
I agree, especially since we can detect this corner case and abort the
translation.
>> I was thinking about renaming the symbol too. We can extend the symbol
>> naming convention we have now and deal with it in klp_resolve_symbols(),
>> but maybe Josh will come up with something clever and cleaner.
> I think this could work well, but (sorry if I understood Joe's idea
> wrongly) not as a linker step. Instead of modifying the linker, I think
> we could create another tool and plug it into the kbuild pipeline prior
> to the livepatch module linking. This way, we would parse the .o elf
> files, check for homonyms and rename them based on a convention that is
> later understood by klp-convert, as suggested.
My knowledge of the build tools is limited, so there was a bunch of
hand-waving you couldn't see when I wrote that paragraph :) But yes,
that is basically the idea: plugging into the kbuild pipeline to give
these some kinda of .o-unique prefix that klp-convert would interpret
and strip accordingly.
> If I am not missing something, this would fix the case where we have
> homonyms pointing to the same or different positions, without additional
> user intervention other then adding the SYMPOS annotations.
>
> If you consider this to be useful I can start experiencing.
>
It's not the highest priority, but even a prototype of how to insert a
script into the pipeline to achieve this would be massively time saving
for myself. If renaming looks easy, we could try to work into the
initial klp-convert patchset... if not, save it for a follow up enhancement.
Thanks,
-- Joe
prev parent reply other threads:[~2019-04-24 19:31 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 15:50 [PATCH v3 0/9] klp-convert livepatch build tooling Joe Lawrence
2019-04-10 15:50 ` [PATCH v3 1/9] livepatch: Create and include UAPI headers Joe Lawrence
2019-04-11 0:32 ` Masahiro Yamada
2019-04-11 14:30 ` Joe Lawrence
2019-04-11 15:48 ` Josh Poimboeuf
2019-04-11 18:41 ` Miroslav Benes
2019-04-10 15:50 ` [PATCH v3 2/9] kbuild: Support for Symbols.list creation Joe Lawrence
2019-04-11 9:18 ` Artem Savkov
2019-04-11 15:18 ` Joe Lawrence
2019-04-11 19:04 ` Miroslav Benes
2019-04-16 14:13 ` Joe Lawrence
2019-04-16 19:02 ` Miroslav Benes
2019-04-10 15:50 ` [PATCH v3 3/9] livepatch: Add klp-convert tool Joe Lawrence
2019-04-10 18:22 ` Joe Lawrence
2019-04-12 9:02 ` Miroslav Benes
2019-04-23 20:35 ` Joe Lawrence
2019-04-24 17:47 ` Miroslav Benes
2019-04-24 21:00 ` Joe Lawrence
2019-04-10 15:50 ` [PATCH v3 4/9] livepatch: Add klp-convert annotation helpers Joe Lawrence
2019-04-10 18:18 ` Joe Lawrence
2019-04-12 9:14 ` Miroslav Benes
2019-04-10 15:50 ` [PATCH v3 5/9] modpost: Integrate klp-convert Joe Lawrence
2019-04-11 15:54 ` Joe Lawrence
2019-04-10 15:50 ` [PATCH v3 6/9] modpost: Add modinfo flag to livepatch modules Joe Lawrence
2019-04-12 10:43 ` Miroslav Benes
2019-04-10 15:50 ` [PATCH v3 7/9] livepatch: Add sample livepatch module Joe Lawrence
2019-04-10 15:50 ` [PATCH v3 8/9] documentation: Update on livepatch elf format Joe Lawrence
2019-04-10 15:50 ` [PATCH v3 9/9] livepatch/selftests: add klp-convert Joe Lawrence
2019-04-12 21:26 ` [PATCH v3 0/9] klp-convert livepatch build tooling Joe Lawrence
2019-04-16 11:37 ` Miroslav Benes
2019-05-03 14:29 ` Joe Lawrence
2019-05-06 14:39 ` Miroslav Benes
2019-04-16 5:24 ` Balbir Singh
2019-04-16 8:29 ` Miroslav Benes
2019-04-16 13:37 ` Joe Lawrence
2019-04-16 13:55 ` Joe Lawrence
2019-04-16 19:09 ` Miroslav Benes
2019-04-17 20:13 ` Joe Lawrence
2019-04-24 18:19 ` Miroslav Benes
2019-04-24 19:13 ` Joao Moreira
2019-04-24 19:23 ` Josh Poimboeuf
2019-04-24 19:31 ` Joe Lawrence [this message]
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=97990f04-9c4c-17ad-901c-5285901d5a7f@redhat.com \
--to=joe.lawrence@redhat.com \
--cc=jeyu@kernel.org \
--cc=jikos@kernel.org \
--cc=jmoreira@suse.de \
--cc=jpoimboe@redhat.com \
--cc=khlebnikov@yandex-team.ru \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=matz@suse.de \
--cc=mbenes@suse.cz \
--cc=nstange@suse.de \
--cc=pmladek@suse.com \
--cc=yamada.masahiro@socionext.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).