lkml.org 
[lkml]   [2019]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 0/9] klp-convert livepatch build tooling
From
Date
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

\
 
 \ /
  Last update: 2019-04-24 21:33    [W:0.084 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site