h8300 SYMBOL_NAME() breakage

[Geert Uytterhoeven]

http://kisskb.ellerman.id.au/kisskb/buildresult/8674258/

arch/h8300/kernel/syscalls.S:6: Error: junk at end of line, first
unrecognized character is `('
arch/h8300/kernel/syscalls.S:17: Error: junk at end of line, first
unrecognized character is `('
arch/h8300/kernel/syscalls.S:18: Error: junk at end of line, first
unrecognized character is `('

Commit e1b5bb6d1236d4ad2084c53aa83dde7cdf6f8eea ("consolidate cond_syscall
and SYSCALL_ALIAS declarations") broke the h8300 build because it removed
the duplicate SYMBOL_NAME from arch/h8300/include/asm/linkage.h, and all
the h8300 asm files include <asm/linkage.h> instead of <linux/linkage.h>.
(yes, this was in -next).

Commit 126de6b20bfb82cc19012d5048f11f339ae5a021 ("linkage.h: fix build
breakage due to symbol prefix handling") broke it even more, by removing
SYMBOL_NAME() and replacing it by __SYMBOL_NAME().

Commit f8ce1faf55955de62e0a12e330c6d9a526071f65 ("Merge tag
'modules-next-for-linus' of
git://git.kernel.org/pub/scm/linuxkernel/git/rusty/linux")
also removed __SYMBOL_NAME(). hidden in a merge conflict resolution.

Interestingly, commit b92021b09df70c1609e3547f3d6128dd560be97f
("CONFIG_SYMBOL_PREFIX: cleanup.") mentions
"arch/h8300/include/asm/linkage.h defines SYMBOL_NAME(), too", so (some)
people should have been aware of the issue?

BTW, arch/h8300/include/asm/linkage.h still has

#undef SYMBOL_NAME_LABEL
#define SYMBOL_NAME_LABEL(_name_) _##_name_##:
#endif

How should this be fixed?
- Re-add SYMBOL_NAME() to arch/h8300/include/asm/linkage.h?
- Kill SYMBOL_NAME() and SYMBOL_NAME_LABEL(), and hardcode the
underscores in the h8300 asm sources?
- Anything else?
I didn't follow the whole symbol prefix discussion that closely.

Thaks for your suggestions?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Linus Torvalds]

On Mon, May 6, 2013 at 5:31 AM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
>
> How should this be fixed?
> - Re-add SYMBOL_NAME() to arch/h8300/include/asm/linkage.h?

No. The whole point was to *not* have these random private definitions.

I guess you could use VMLINUX_SYMBOL() and include <linux/export.h>
and then use VMLINUX_SYMBOL(). Although..

> - Kill SYMBOL_NAME() and SYMBOL_NAME_LABEL(), and hardcode the
> underscores in the h8300 asm sources?

. I think this is what everybody else does. Although sometimes that
underscore depends on what the linkage format is (ie historically
a.out vs elf etc). We pretty much expect ELF these days, but maybe
other conditional reasons exist - so there may be a reason you don't
want to do the hardcoding (although on h8300 it seems to be
unconditional at least for now).

Linus

[Geert Uytterhoeven]

On Mon, May 6, 2013 at 4:30 PM, Linus Torvalds
<torv...@linux-foundation.org> wrote:
> On Mon, May 6, 2013 at 5:31 AM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
>>
>> How should this be fixed?
>> - Re-add SYMBOL_NAME() to arch/h8300/include/asm/linkage.h?
>
> No. The whole point was to *not* have these random private definitions.
>
> I guess you could use VMLINUX_SYMBOL() and include <linux/export.h>
> and then use VMLINUX_SYMBOL(). Although..
>
>> - Kill SYMBOL_NAME() and SYMBOL_NAME_LABEL(), and hardcode the
>> underscores in the h8300 asm sources?
>

> .. I think this is what everybody else does. Although sometimes that

> underscore depends on what the linkage format is (ie historically
> a.out vs elf etc). We pretty much expect ELF these days, but maybe
> other conditional reasons exist - so there may be a reason you don't
> want to do the hardcoding (although on h8300 it seems to be
> unconditional at least for now).

Thx, will fix.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[James Hogan]

On 06/05/13 13:31, Geert Uytterhoeven wrote:
> Commit e1b5bb6d1236d4ad2084c53aa83dde7cdf6f8eea ("consolidate cond_syscall
> and SYSCALL_ALIAS declarations") broke the h8300 build because it removed
> the duplicate SYMBOL_NAME from arch/h8300/include/asm/linkage.h, and all
> the h8300 asm files include <asm/linkage.h> instead of <linux/linkage.h>.
> (yes, this was in -next).
>
> Commit 126de6b20bfb82cc19012d5048f11f339ae5a021 ("linkage.h: fix build
> breakage due to symbol prefix handling") broke it even more, by removing
> SYMBOL_NAME() and replacing it by __SYMBOL_NAME().

Yes, sorry about that. I had assumed h8300 still referred to it's own
definition of SYMBOL_NAME from arch/h8300/include/asm/linkage.h, which
was still intact on modules-next where I had last checked it.

Cheers
James