On Fri, 19 Aug 2016 10:37:00 +0200
Michal Marek [off-list ref] wrote:

On 2016-08-19 07:09, Stephen Rothwell wrote:

quoted

Hi Nick,

On Fri, 19 Aug 2016 13:38:54 +1000 Stephen Rothwell [off-list ref] wrote:  

quoted

On Thu, 18 Aug 2016 11:09:48 +1000 Nicholas Piggin [off-list ref] wrote:  

quoted

On Wed, 17 Aug 2016 14:59:59 +0200
Michal Marek [off-list ref] wrote:
    

quoted

On 2016-08-17 03:44, Stephen Rothwell wrote:      

quoted

After merging the kbuild tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:

WARNING: 25 bad relocations
c000000000cf2570 R_PPC64_ADDR64    __crc___arch_hweight16        

[...]      

quoted

Introduced by commit

  9445aa1a3062 ("ppc: move exports to definitions")

I have reverted that commit for today.

[cc-ing the ppc guys for clues - also involved is commit

  22823ab419d8 ("EXPORT_SYMBOL() for asm")
]        

FWIW, I see these warnings as well. Any help from ppc developers is
appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm
symbols (their CRCs actually)?      

The dangling relocation is a side effect of linker unable to resolve the
reference to the undefined weak symbols. So the real question is, why has
genksyms not overridden these symbols with their CRC values?

This may not even be powerpc specific, but  I'll poke at it a bit more
when I get a chance.    

Not sure if this is relevant, but with the commit reverted, the
__crc___... symbols are absolute.

00000000f55b3b3d A __crc___arch_hweight16  

Ignore that :-)

I just had a look at a x86_64 allmodconfig result and it looks like the
weak symbols are not resolved their either ...

I may be missing something, but genksyms generates the crc's off the
preprocessed C source code and we don't have any for the asm files ...  

Of course you are right. Which means that we are losing type information
for these exports for CONFIG_MODVERSIONS purposes. I guess it's
acceptable, since the asm functions are pretty basic and their
signatures do not change.

I don't completely agree. It would be nice to have the functionality
still there.

What happens if you just run cmd_modversions on the as rule? It relies on
!defined(__ASSEMBLY__), but we're feeding the result to genksyms, not as.
It would require the header be included in the .S file and be protected for
asm builds.

Stephen wasn't a fan of suck a hack and I can't say I blame him. Another
possibility I suppose is an EXPORT_SYMBOL_ASM() variant that takes string
containing C function declaration and just inserts it as an assembler
comment somewhere that genksysms can find.


Thanks,
Nick