[PATCH v4 3/3] kallsyms: remove --page-offset command line option

[Ard Biesheuvel]

On 9 February 2016 at 20:28, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> On Tue, 9 Feb 2016, Ard Biesheuvel wrote:
>
>> On 9 February 2016 at 17:09, Chris Brandt <Chris.Brandt at renesas.com> wrote:
>> > On 9 Feb 2016, Ard Biesheuvel wrote:
>> >
>> >>diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
>> >>index 02473b71643b..32c8d43590af 100644
>> >>--- a/scripts/kallsyms.c
>> >>+++ b/scripts/kallsyms.c
>> >>@@ -63,7 +63,6 @@ static unsigned int table_size, table_cnt;
>> >> static int all_symbols = 0;
>> >> static int absolute_percpu = 0;
>> >> static char symbol_prefix_char = '\0';
>> >>-static unsigned long long kernel_start_addr = 0;
>> >> static int base_relative = 0;
>> >
>> >
>> >
>> > You removed kernel_start_addr, but you didn't remove all the instances of it in the file (you did remove them all in V2 though).
>> >
>> > So, now I get:
>> >
>> >   CC      scripts/mod/devicetable-offsets.s
>> > ../scripts/kallsyms.c: In function 'record_relative_base':
>> > ../scripts/kallsyms.c:740:6: error: 'kernel_start_addr' undeclared (first use in this function)
>> >   if (kernel_start_addr > 0) {
>> >       ^
>> > ../scripts/kallsyms.c:740:6: note: each undeclared identifier is reported only once for each function it appears in
>> > make[2]: *** [scripts/kallsyms] Error 1
>> >
>>
>> That is because this patch
>>
>> http://ozlabs.org/~akpm/mmots/broken-out/kallsyms-add-support-for-relative-offsets-in-kallsyms-address-table-v5.patch
>>
>> is also in flight, via akpm's tree, and is expected to hit -next
>> tomorrow. That patch removes this reference (or alternatively, will
>> not introduce it anymore if akpm decides to fold it into
>> http://ozlabs.org/~akpm/mmots/broken-out/kallsyms-add-support-for-relative-offsets-in-kallsyms-address-table.patch
>> before submitting it)
>>
>> Going forward, it probably makes sense to only submit #1 of this
>> series for v4.6, and queue the remaining two after the merge window.
>
> Well... If akpm agrees, you could get those patches back and create a
> tree of your own with all ACKs for this work to avoi all this patch
> ordering dependency nightmare (including the work that depends on this)
> and submit it upstream (to Linus maybe?) while having it merged in
> linux-next in the mean time.
>

All these changes are related to my KASLR series for arm64 in one way
or the other, some of which is en route via akpm's tree (including the
generic kallsyms changes that these patches are based on) and some via
Catalin's tree. If Russell is ok to take this #1 for v4.6, I am happy
to sit on the remaining two for a while (which essentially only remove
dead code once #1 is applied)

Thanks,
Ard.