Messages in this thread Patch in this message | | | Date | Sun, 24 Jan 2016 09:21:04 +0100 | Subject | Re: Problems with commit 'kallsyms: add support for relative offsets in kallsyms address table' (in mmotm) | From | Ard Biesheuvel <> |
| |
On 24 January 2016 at 08:06, Guenter Roeck <linux@roeck-us.net> wrote: > On 01/23/2016 10:10 PM, Ard Biesheuvel wrote: >> >> >> >>> On 24 jan. 2016, at 03:35, Guenter Roeck <linux@roeck-us.net> wrote: >>> >>>> On 01/23/2016 06:06 PM, Guenter Roeck wrote: >>>> Hi, >>>> >>>> I see runtime problems with the current mmotm branch. All qemu mips >>>> targets >>>> (32 and 64 bit, big and little endian) are stuck in boot after this >>>> commit. >>>> >>>> Bisect points to commit d13682e4d9d2 ("kallsyms: add support for >>>> relative offsets >>>> in kallsyms address table". Disabling CONFIG_KALLSYMS_BASE_RELATIVE >>>> fixes the problem, >>>> ie I can boot the image with qemu. >>>> >>>> Bisect log is attached. >>>> >>>> Playing with the problem, I found the following: >>>> >>>> 1) The problem is only seen with a toolchain using binutils 2.22, but >>>> not >>>> with a toolchain using binutils 2.25. The compiler configuration may >>>> be >>>> different for both toolchains. >>>> 2) Message "kallsyms failure: absolute symbol value 0xffffffff807afd14 >>>> out of range >>>> in relative mode" (twice) when using the toolchain with binutils >>>> 2.22. >>>> This does not cause the build to fail, though. >>>> 3) kallsyms_sym_address() parameter variable type is "int". In the >>>> calling code, >>>> the variable type used is "unsigned long". That has no impact on the >>>> problem, >>>> though. >>> >>> >>> An additional data point: When using the older toolchain, many symbols in >>> System.map >>> are marked "A". >>> ffffffff80100000 A _text >>> With the more recent toolchain, the same symbols are marked "T". >>> ffffffff80100000 T _text >>> >> >> Thanks for the analysis. It is surprising that the build does not fail >> when this occurs, and the subsequent hangs themselves are probably caused by >> missing kallsyms data. >> > Yes, I wondered why the build doesn't fail. Seems odd. > >> scripts/kallsyms.c ignores all A symbols except _text, which is actually a >> relative symbol by nature so we can simply assume it is relative (i.e., >> override it as T) >> >> Re x86_64 !SMP, any build time errors there as well? Likewise for sparc32? >> > > Yes, same kind of errors for both. For x86_64/nosmp I also get the error > message > when using the Ubuntu native toolchain, so it doesn't seem to be (directly) > related to binutils 2.22 vs. 2.25 for that architecture. > > Runtime behavior is a bit different for the different architectures. > x86_64 dies silently without any console output, mips just hangs, > and sparc32 gets a panic with NULL pointer access. > Of course, with missing kallsyms data all bets are off. > >> >> Thanks again, and sorry for the trouble, > > > No worries. Hope you'll get this sorted out. >
OK, there's an additional issue in my latest version: the kallsyms_relative_base value itself is not relocated.
If you have more time to burn on this, could you try the following on top? (If not, that is also fine, I will look into it myself on Monday)
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c index 5ab13394dfd9..0f43f0751d47 100644 --- a/scripts/kallsyms.c +++ b/scripts/kallsyms.c @@ -137,8 +137,10 @@ static int read_symbol(FILE *in, struct sym_entry *s) sym++;
/* Ignore most absolute/undefined (?) symbols. */ - if (strcmp(sym, "_text") == 0) + if (strcmp(sym, "_text") == 0) { _text = s->addr; + stype = 'T'; + } else if (check_symbol_range(sym, s->addr, text_ranges, ARRAY_SIZE(text_ranges)) == 0) /* nothing to do */; @@ -406,7 +408,7 @@ static void write_src(void)
if (base_relative) { output_label("kallsyms_relative_base"); - printf("\tPTR\t%#llx\n", relative_base); + printf("\tPTR\t_text - %#llx\n", _text - relative_base); printf("\n"); }
Thanks, Ard.
| |