Re: [PATCH 04/10] module: make MODULE_SYMBOL_PREFIX into a CONFIG option

[Mike Frysinger]

On Tue, Nov 3, 2009 at 08:46, Paul Mundt wrote:
> On Tue, Nov 03, 2009 at 08:39:29AM -0500, Mike Frysinger wrote:
>> On Tue, Nov 3, 2009 at 08:29, Paul Mundt wrote:
>> > Having it in the Kconfig also makes it a nuisance for platforms that can
>> > use -elf and -linux toolchains for the same tree for different platforms.
>> > It would be nice to have this supported in such a way that we can just
>> > set a flag from the Makefile and have a compiler test that determines
>> > whether it is necessary or not.
>>
>> what arch is this an issue for ? Âthe only symbol prefixed arches are
>> Blackfin and H8300, and they dont provide toolchains that omit the
>> prefix.
>
> No, those are the only symbol prefixed platforms enabled in the kernel at
> present because neither one ships different toolchains.

and most likely never will.  the Blackfin symbol prefix is every
where, userspace included.

> The symbol prefixing itself is more an artifact of a -elf target
> contrasted with a -linux one than anything "platform" specific. Thus, any
> nommu platform using a bare metal or -elf toolchain can easily be used
> for building the kernel if this can be supported in a clean way. As such,
> a config option is not useful.

which has no bearing on the Blackfin case as every toolchain target
can currently be used to build the kernel

>> trying to enable symbol prefix support dynamically based on the
>> toolchain is a bad idea and pretty fragile. Âthe arch-specific
>> assembly code would have to be all rewritten to wrap all C-visible
>> symbols with a macro like VMLINUX_SYMBOL().
>
> There is nothing fragile about it, symbols are either prefixed or they
> aren't. The common case for things like the syscall table obiously have
> to be wrapped, but so what? C_SYMBOL_PREFIX() used to be the norm back in
> the day, so it obiously worked well enough for the common case.

it worked well when it was the *common* case as you said.  when people
rarely use it (which is what happens today), things constantly break
because no one tests it, the usage is awkward, and it's an artifact
that shouldnt exist in the first place.

>> i say let anyone who actually has such a system and wants to do such a
>> crazy ass thing put together a working arch first before we worry
>> about it. Âthe current code doesnt preclude dynamic hooking anyways
>> (manually adding -DCONFIG_xxx to CPPFLAGS).
>
> You talk about fragile bad ideas and then throw out defining Kconfig
> variables from Makefiles? This simply has no place in the Kconfig space,
> as it is now and always has been a toolchain property, not an
> architectural/platform one.

my point was that it can easily be mixed.  i personally could care
less where the symbol is declared so long as it's declared just once.

> The other thing you seem to have ignored is that pretty much everyone has
> such a system, it's only crippled platforms like blackfin and h8300 that
> don't support toolchains without the prefix.

"cripple" is exactly the right word.  why in the world do you want to
cripple people that dont need it ?  attempting to support busted
toolchains by forcing even more symbol prefix crap throughout an arch
makes no sense at all.  use the -fno-leading-underscore gcc option if
you want to re-use a non-standard symbol prefixed elf compiler to
build an arch.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/