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
