lkml.org 
[lkml]   [2022]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v2] x86: Avoid relocation information in final vmlinux
From
On 11/23/22 18:45, H. Peter Anvin wrote:
> On November 23, 2022 7:54:29 AM PST, Borislav Petkov <bp@alien8.de> wrote:
>> On Wed, Nov 23, 2022 at 04:43:20PM +0100, Petr Pavlu wrote:
>>> The only post-link analysis tool in this case should be arch/x86/tools/relocs.
>>> It produces a vmlinux.relocs file which is appended to vmlinux.bin. This is
>>> all internal to the Linux build. I'm not aware of any external tooling, such
>>> as kernel debuggers, that would require this relocation information in
>>> vmlinux.
>>
>> It would be good to know why --emit-relocs was added in the first place
>> - that might give us a hint. Lemme talk to Micha.
>>
>>> The size command used in your example includes only allocatable code, data and
>>> bss sections. It does not show size of any relocation sections.
>>
>> This:
>>
>> 361M vmlinux.before
>> 361M vmlinux.after
>>
>> is simple ls output.
>>
>> Maybe I need something else enabled in my .config which would show this
>> significant difference *and* *explain* it.
>>
>> Thx.
>>
>
> The real question is: why does anyone care about the size of the vmlinux file specifically?

The vmlinux file is typically collected by various package build recipes, such
as distribution spec files, including the kernel's own binrpm-pkg target.
Users then have available a version of their kernel in the ELF format that
they can use with debuggers, disassemblers and other standard ELF tooling.

My initial motivation was to reduce size of vmlinux when debuginfo is enabled.
The present .rela.debug_* sections have a significant impact on the size but
they are not actually needed by debuggers. Stripping this data then saves
bandwidth and disk space required to work with vmlinux for the target users.

Petr

\
 
 \ /
  Last update: 2022-11-24 11:05    [W:0.316 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site