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

[Nicolas Pitre]

On Tue, 9 Feb 2016, Ard Biesheuvel wrote:

> 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)

OK makes sense.


Nicolas