Messages in this thread | | | Date | Mon, 21 Nov 2011 11:16:04 -0800 | From | David Daney <> | Subject | Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table. |
| |
On 11/21/2011 10:50 AM, Mike Frysinger wrote: > On Monday 21 November 2011 13:25:36 David Daney wrote: >> On 11/20/2011 03:22 PM, Mike Frysinger wrote: >>> On Friday 18 November 2011 14:37:44 David Daney wrote: >>>> + switch (w2(ehdr->e_machine)) { >>>> + default: >>>> + fprintf(stderr, "unrecognized e_machine %d %s\n", >>>> + w2(ehdr->e_machine), fname); >>>> + fail_file(); >>>> + break; >>>> + case EM_386: >>>> + case EM_MIPS: >>>> + case EM_X86_64: >>>> + break; >>>> + } /* end switch */ >>> >>> unlike recordmcount, this file doesn't do anything arch specific. so >>> let's just delete this and be done. >> >> Not really true at this point. We don't know the size or layout of the >> architecture specific exception table entries, likewise for >> CONFIG_ARCH_HAS_SORT_EXTABLE, we don't even know how to do the comparison. > > all of your code that i could see is based on "is it 32bit or is it 64bit". > there is no code that says "if it's x86, we need to do XXX".
At this point there is no need. MIPS, i386 and x86_64 all store the key in the first word of a two word structure.
If there were some architecture that didn't fit this model, we would have to create a special sorting function and select it (and perhaps other parameters as well) in that switch statement.
> > when i look in the kernel, we have common code behind ARCH_HAS_SORT_EXTABLE. > so you could easily do the same thing: > > scripts/sortextable.c: > #ifdef ARCH_HAS_SORT_EXTABLE > switch (w2(ehdr->e_machine)) { > default: > fprintf(stderr, "unrecognized e_machine %d %s\n", > w2(ehdr->e_machine), fname); > ... return a unique exit code like 77 ... > break; > /* add arch sorting info here */ > } /* end switch */ > #endif > > kernel/extable.c: > #if defined(ARCH_HAS_SORT_EXTABLE)&& !defined(ARCH_HAS_SORTED_EXTABLE) > void __init sort_main_extable(void) > { > sort_extable(__start___ex_table, __stop___ex_table); > } > #endif >
Yes, I am familiar with that code. One thing to keep in mind is that the compiler has access to struct exception_table_entry, and can easily figure out both how big the structure is *and* where the insn field is within the structure.
This is not the case for the author of sortextable. Except for MIPS, MIPS64, i386 and x86_64, I know neither the size of struct exception_table_entry, nor the offset of its insn field.
For those with knowledge of the inner working of other architectures, it may be as simple as a two line patch to add support, but it isn't something that I want to take responsibility for at this point
> this way all the people not doing unique stuff work out of the box. only the > people who are doing funky stuff need to extend things.
I didn't want to include something like this that I cannot test. An unsorted (or improperly sorted) exception table is not necessarily something that will be noticeable by simply booting the kernel. Your only indication may be a panic or OOPS under rarely encountered conditions.
David Daney
| |