Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux