2009-08-21 02:07:30 R_luimm16/R_huimm16 not relocated anymore in module

Filip Van Rillaer (BELGIUM)

Message: 79099

Hello,

I updated to the latest version of the kernel/distribution and toolchan in the trunk of subversion. I see that the variable with property R_huimm16/R_luimm16 is not reloacted anymore (resulting in accessing address 0x0). Please find here a dump of the code generated by gcc that causes the problem.

8a: 4a e1 00 00 P2.H = 0x0; /* ( 0) P2=0x400 */

8c: R_huimm16 tldbg_Level

8e: 28 e6 26 00 [P5 + 0x98] = R0;

92: 0a e1 00 00 P2.L = 0x0; /* ( 0) P2=0x0 <UartInterruptHandlerRx> */

94: R_luimm16 tldbg_Level

96: 11 91 R1 = [P2];

I think that the problem is in the file arch/blackfin/kernel/module.c. version 6856. Please comment.

BR,

Filip

TranslateQuoteReplyEditDelete

2009-08-21 02:11:26 Re: R_luimm16/R_huimm16 not relocated anymore in module

Mike Frysinger (UNITED STATES)

Message: 79100

you built your module wrong. use -mlong-calls.

QuoteReplyEditDelete

2009-08-21 02:30:09 Re: R_luimm16/R_huimm16 not relocated anymore in module

Filip Van Rillaer (BELGIUM)

Message: 79101

Hi Mike,

Thank you for your super-fast answer, but I am already using the -mlong-calls option, maybe there is something else wrong in my compilation command? Please have look:

bfin-uclinux-gcc -c -DBF537 -DBFLIN -Wfatal-errors -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Wdeclaration-after-statement -Wno-pointer-sign -fno-common -Wno-switch-enum -fomit-frame-pointer -g -fno-strict-aliasing -Wstrict-aliasing=0 -D__KERNEL__ -DMODULE -isystem /home/fiva/usa/uclinux-dist-oldsvn/linux-2.6.x/include -isystem /home/fiva/usa/usaoutput-uclinux/lib/gcc/bfin-uclinux/4.1.2/include -include /home/fiva/usa/uclinux-dist-oldsvn/linux-2.6.x/include/linux/autoconf.h -fno-common -O2 -mlong-calls -nostdinc -fno-stack-protector -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(uart)" -D"KBUILD_MODNAME=KBUILD_STR(uart)" -I/home/fiva/usa/uclinux-dist-oldsvn/linux-2.6.x/arch/blackfin/include -I/home/fiva/usa/uclinux-dist-oldsvn/linux-2.6.x/arch/blackfin/mach-bf537/include -I"/home/fiva/svn/cm/trunktemp/inc/bfuclinscs_softdtp_resa_cl_dbg" -I"/home/fiva/svn/cm/trunktemp" -I"/home/fiva/svn/cm/trunktemp/common/tlvcom/builtinkern/src/bfuclin" -I"/home/fiva/svn/cm/trunktemp/common/tlvcom/builtinkern/src" -I"/home/fiva/svn/cm/trunktemp/common/tlvcom/builtinkern/obj/bfuclinscs_softdtp_resa_cl/debug" -o"obj/bfuclinscs_softdtp_resa_cl/debug/uart.o" "/home/fiva/svn/cm/trunktemp/common/tlvcom/builtinkern/src/bfuclin/uart.c"

BR,

Filip

TranslateQuoteReplyEditDelete

2009-08-21 04:35:03 Re: R_luimm16/R_huimm16 not relocated anymore in module

Mike Frysinger (UNITED STATES)

Message: 79103

are you able to post the code for us to look at (compile/disassemble/test) ? presumably you're using the 2009R1 toolchain or newer ...

QuoteReplyEditDelete

2009-08-21 04:39:44 Re: R_luimm16/R_huimm16 not relocated anymore in module

Filip Van Rillaer (BELGIUM)

Message: 79104

Hi Mike,

I'll try to reproduce the problem in a simple example and post it.

bfin-uclinux-gcc --version

bfin-uclinux-gcc (GCC) 4.1.2 (ADI svn)

svn info

Path: .

URL: svn://firewall-sources.blackfin.uclinux.org:80/svn/toolchain/trunk

Repository Root: svn://firewall-sources.blackfin.uclinux.org:80/svn/toolchain

Repository UUID: 2adf4935-75e9-4407-93b2-34b21a1880a4

Revision: 3581

Node Kind: directory

Schedule: normal

Last Changed Author: mteris

Last Changed Rev: 3581

Last Changed Date: 2009-08-14 12:17:13 +0200 (Fri, 14 Aug 2009)

BR,

Filip

TranslateQuoteReplyEditDelete

2009-08-21 06:55:09 Re: R_luimm16/R_huimm16 not relocated anymore in module

Robin Getz (UNITED STATES)

Message: 79105

Filip:

As Mike is saying -- those relocations were removed -- since if your module is built properly - it should not include those specific relocation types.

How is tldbg_Level being included/defined? It looks like something from your code?

-Robin

QuoteReplyEditDelete

2009-08-21 08:46:36 Re: R_luimm16/R_huimm16 not relocated anymore in module

Filip Van Rillaer (BELGIUM)

Message: 79116

Hello Robin,

<<those relocations were removed>>

Do you mean that the toolchain should not generate those relocations anymore (whatever options you also give to the gcc tools)?

tldbg_Level is a global variable in our code. This particular code is from an interrupt service routine. But I don't think that that is relevant for the problem as I see those R_huimm16/R_luimm16 also appearing in the init_module of the dumped code. I the function that I am using has the attribute l1_text, then data in the code are not relocated correctly (so the point to address 0x0), if I remove the attribute (the generated code for that function is still the same, only it dissappears from the .l1.text section in the dump) then the program runs fine.

I am trying to make a simple testprogram that demonstrates the problem, but until now I didn't succeed. Anyhow maybe it does already rings a bell.

BR,

Filip

TranslateQuoteReplyEditDelete

2009-08-21 09:08:27 Re: R_luimm16/R_huimm16 not relocated anymore in module

Bernd Schmidt (GERMANY)

Message: 79118

Actually, those particular relocations are necessary and have not been removed.

We'll need a testcase to do anything other than guess.

QuoteReplyEditDelete

2009-08-21 11:55:34 Re: R_luimm16/R_huimm16 not relocated anymore in module

Robin Getz (UNITED STATES)

Message: 79122

Oops - yeah - I was thinking there were some relocations removed - but they were R_pcrel24 & R_pcrel24_jump_l - the R_[lh]uimm16 are still there (I should look before I speak).

But since they were only removed on the trunk, not the 2009 branch -- it shouldn't matter...

-Robin

QuoteReplyEditDelete

2009-08-21 16:34:57 Re: R_luimm16/R_huimm16 not relocated anymore in module

Mike Frysinger (UNITED STATES)

Message: 79128

if you're just looking at objdump and assuming it's wrong, you arent using the tool properly. you have to use the -r option to display relocs that the kernel will process for you.

QuoteReplyEditDelete

2009-08-26 07:17:08 Re: R_luimm16/R_huimm16 not relocated anymore in module

Filip Van Rillaer (BELGIUM)

Message: 79228

Hello,

Sorry for the delay and thank you all for the usefull input.

Please find here my program that demonstrates the problem. If the function SampleRateSet is in l1-memory, then the memory access after the line with the 'emuexcpt' instruction will not be relocated correctly (though it is in the relocation table as bfin-uclinux-objdump -r shows at offset 4 and offset 8 of .l1.text). If the function is not in l1-memory, the code will be relocated correctly.

BR, Filip

debug.txt

my_module.c

debugr.txt

TranslateQuoteReplyEditDelete

2009-08-26 08:19:19 Re: R_luimm16/R_huimm16 not relocated anymore in module

Filip Van Rillaer (BELGIUM)

Message: 79234

Hello,

FYI, my kernel version is

URL: svn://firewall-sources.blackfin.uclinux.org:80/svn/linux-kernel/trunk

Repository Root: svn://firewall-sources.blackfin.uclinux.org:80/svn/linux-kernel

Repository UUID: 526b6c2d-f592-4532-a319-5dd88ccb003d

Revision: 7234

Node Kind: directory

Schedule: normal

Last Changed Author: hennerich

Last Changed Rev: 7234

Last Changed Date: 2009-08-25 04:49:17 +0200 (Tue, 25 Aug 2009)

BR, Filip

TranslateQuoteReplyEditDelete

2009-08-26 18:43:08 Re: R_luimm16/R_huimm16 not relocated anymore in module

Mike Frysinger (UNITED STATES)

Message: 79249

i'll take a look. as long as you're only seeing this problem on trunk where we rewrote a bunch of the module loading code and not the branch which is still using the same module code we have for a long time.

QuoteReplyEditDelete

2009-08-26 22:50:18 Re: R_luimm16/R_huimm16 not relocated anymore in module

Mike Frysinger (UNITED STATES)

Message: 79260

isram_memcpy() appears to be broken. this should fix things for you while we figure out what's wrong:

sed -i s:isram_memcpy:dma_memcpy: arch/blackfin/kernel/module.c

QuoteReplyEditDelete

2009-08-27 02:45:42 Re: R_luimm16/R_huimm16 not relocated anymore in module

Mike Frysinger (UNITED STATES)

Message: 79269

ive opened a tracker for the issue here: blackfin.uclinux.org/gf/tracker/5464

QuoteReplyEditDelete