Messages in this thread | | | Date | Thu, 3 Mar 2011 14:44:15 +0000 | Subject | Re: [RFC PATCH] ARM: Use generic BUG() handler | From | Dave Martin <> |
| |
On Thu, Mar 3, 2011 at 2:11 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Wed, Mar 02, 2011 at 10:59:50AM +0000, Dave Martin wrote: >> + asm volatile("1:\t" __bug_instr "\n" q \ >> + ".pushsection .rodata.str, \"a\"\n" \ >> + "2:\t.asciz \"" #__file "\"\n" \ >> + ".popsection\n" \ > > Doesn't this mean we end up with multiple file names?
Hmmm, yes, you're right.
After a bit of digging in the documentation, I find that ELF supports mergable string sections though, so
.pushsection .rodata.str, "aMS", 1 .asciz __FILE__ .popsection
...actually looks like it ought to do the right thing: duplicate strings in the section get merged during linking, even if there are duplicates from a single object.
Simple experiments suggest that the linker does this right, even merging distinct strings which share a common suffix. Do we use this elsewhere in the kernel? It it's not already used, it could be a win for any large, static string tables.
> >> + ".pushsection __bug_table,\"a\"\n" \ >> + "3:\t.word 1b, 2b\n" \ >> + "\t.hword " #__line ", 0\n" \ >> + ".popsection" \ >> + unreachable(); \ >> +} while (0) > > Second problem is that the above produces this: > > 1: .word 0xec000000 > .pushsection .rodata.str, "a" > 2: .asciz "__FILE__" > .popsection > .pushsection __bug_table,"a" > 3: .word 1b, 2b > .hword __LINE__, 0 > .popsection > > which is clearly not what we want.
Indeed. I did say I hadn't tested it :)
> Adding another level of indirection > starts to get closer to what we desire: > > 1: .word 0xec000000 > .pushsection .rodata.str, "a" > 2: .asciz ""t.c"" > .popsection > .pushsection __bug_table,"a" > 3: .word 1b, 2b > .hword 19, 0 > .popsection > > but we're still ending up with multiple strings containing the filename, > which is going to excessively bloat the kernel no end. >
We'd need to remove the duplicate quotes, too.
For the .org <blah> + sizeof (struct bug_entry) problem, Will pointed out that there's a BUILD_BUG_ON() macro which we could used to avoid silently producing a bad build if the result of that sizeof isn't what we expect.
So I still think it could work ... but it's a bit of an ugly hack I confess.
Cheers ---Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |