>>> Sam Ravnborg <sam@xxxxxxxxxxxx> 22.04.08 20:07 >>>
>Hi Jan.
>
>> --- linux-2.6.25/arch/x86/kernel/vmlinux_64.lds.S 2008-04-17 04:49:44.000000000 +0200
>> +++ 2.6.25-bug-table-rodata/arch/x86/kernel/vmlinux_64.lds.S 2008-03-04 11:14:13.000000000 +0100
>> @@ -19,7 +19,7 @@ PHDRS {
>> data PT_LOAD FLAGS(7); /* RWE */
>> user PT_LOAD FLAGS(7); /* RWE */
>> data.init PT_LOAD FLAGS(7); /* RWE */
>> - note PT_NOTE FLAGS(4); /* R__ */
>> + note PT_NOTE FLAGS(0); /* ___ */
>> }
>
>Is this intentional in this patch?
Yes. While it may be possible to do this separately, it seemed safer to
me to keep it together since I only tested it this way.
>> SECTIONS
>> {
>> @@ -40,16 +40,14 @@ SECTIONS
>> _etext = .; /* End of text section */
>> } :text = 0x9090
>>
>> + NOTES :text :note
>> +
>> . = ALIGN(16); /* Exception table */
>> __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
>> __start___ex_table = .;
>> *(__ex_table)
>> __stop___ex_table = .;
>> - }
>> -
>> - NOTES :text :note
>> -
>> - BUG_TABLE :text
>> + } :text = 0x9090
>
>And I do not see the 0x9090 justified.
>Is this something to do with the fact that 0x90 equals NOP on x86?
Yes, for consistency I think this ought to be repeated here - while
not strictly necessary (__ex_table is data, hence padding with
zeroes rather than NOPs would be fine), it seems more safe to have
it here so that we don't catch occasional linker bugs. Ultimately I
would think __ex_table should go into RODATA, too, which would
eliminate the question.
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
