linux-kernel - Re: [PATCH] alpha: link failure fix

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 21 Jun 2008 22:17:42 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Richard Henderson <rth@...ddle.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] alpha: link failure fix

On Sat, Jun 21, 2008 at 03:26:21AM +0400, Ivan Kokshaysky wrote:
> With built-in scsi disk driver, the final link fails with a following
> error:
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o:
> defined in discarded section `.exit.text' of drivers/built-in.o
> 
> This happens with -Os (CONFIG_CC_OPTIMIZE_FOR_SIZE=y) with all gcc-4
> versions, and also with -O2 and gcc-4.3.
> 
> The problem is in sd.c:sd_major() being inlined into __exit function
> exit_sd(), and the compiler generating a jump table in .rodata section
> for the 'switch' statement in sd_major(). So we have references to
> discarded section.
> 
> Fixed with a big hammer in the form of -fno-jump-tables.
> 
> Note that jump tables vs. discarded sections is a generic problem,
> other architectures are just lucky not to suffer from it.
Most other architectures would only notice when the exit function
is called because they do late discardning og the exit section.
alpha (and sparc) are some of the few architectures that discard exit
section at link time thus you will see this much sooner
than the others.

> But with
> a slightly more complex switch/case statement it can be reproduced
> on x86 as well. So maybe at some point we should consider
> -fno-jump-tables as a generic compile option...
Are the any size penalties here?
I assume there are a minimal performance penalty.

	Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/