On Monday 21 November 2011 14:16:04 David Daney wrote:

On 11/21/2011 10:50 AM, Mike Frysinger wrote:

quoted

On Monday 21 November 2011 13:25:36 David Daney wrote:

quoted

On 11/20/2011 03:22 PM, Mike Frysinger wrote:

quoted

On Friday 18 November 2011 14:37:44 David Daney wrote:

quoted

+	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.

that's trivial to check:
	sed -n '/^struct exception_table_entry/,/};/p'\
		arch/*/include/asm/uaccess* include/asm-generic/uaccess.h 

and indeed, the only arches that don't follow this model are the ones that 
define ARCH_HAS_SORT_EXTABLE.

quoted

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.

a trivial sed/grep gets you the answer: they're all the same

quoted

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.

this is what linux-next is for :)
-mike