> On 24 jan. 2016, at 19:01, Guenter Roeck <li...@roeck-us.net> wrote: > > On 01/24/2016 09:20 AM, Ard Biesheuvel wrote: > [ ... ] >>>> 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"); >>>> } >>> >>> Does not help. >>> >> >> For x86? Or none of them? >> > > I tested sparc32 and x86_64/nosmp. Doesn't help for any of them. > sparc32 has the following absolute symbols. > > f035a420 A _etext > f03d9000 A _sdata > f03de8c4 A jiffies > f03f8860 A _edata > f03fc000 A __init_begin > f041bdc8 A __init_text_end > f0423000 A __bss_start > f0423000 A __init_end > f044457d A __bss_stop > f044457d A _end >
Any clue why these don't get dropped? Am I missing something? Afaict A symbols get dropped unless they are whitelisted (i.e., the few ia64 ones) > This results in: > > kallsyms failure: absolute symbol value 0xf035a420 out of range in relative > mode > > This is with binutils 2.22. I didn't test with binutils 2.25 for sparc, or > re-test mips. > > > Looks like I'll need to add more test cases with binutils 2.22 vs. 2.25 for > various > architectures, as well as more SMP vs. !SMP builds. > Thanks once again