Hi Shenghao,
On Tue, Oct 3, 2023 at 12:47 PM Ding, Shenghao shenghao-ding@ti.com wrote:
-----Original Message----- From: Geert Uytterhoeven geert@linux-m68k.org Sent: Tuesday, October 3, 2023 3:24 AM To: Ding, Shenghao shenghao-ding@ti.com Cc: broonie@kernel.org; robh+dt@kernel.org; andriy.shevchenko@linux.intel.com; lgirdwood@gmail.com; perex@perex.cz; pierre-louis.bossart@linux.intel.com; Lu, Kevin kevin-lu@ti.com; 13916275206@139.com; alsa-devel@alsa-project.org; linux- kernel@vger.kernel.org; liam.r.girdwood@intel.com; mengdong.lin@intel.com; Xu, Baojun baojun.xu@ti.com; thomas.gfeller@q-drop.com; Gupta, Peeyush peeyush@ti.com; Navada Kanyana, Mukund navada@ti.com; tiwai@suse.de Subject: [EXTERNAL] Re: [PATCH v1] ASoC: tas2781: fixed compiling issue in m68k
Hi Shenghao,
Thanks for your patch!
On Mon, Oct 2, 2023 at 4:38 PM Shenghao Ding shenghao-ding@ti.com wrote:
fixed m68k compiling issue: mapping table can save code field; storing the
Please replicate the actual error message from the compiler, so it is recorded in the commit description, and easy to find when someone searches for the actual error message
From the Reported-by (which is not included in the actual description, as it is below the "---"):
{standard input}: Assembler messages: >> {standard input}:992: Error: value -148 out of range {standard input}:992: Error: value of ffffff6c too large for field of 1 byte at0000045f
dev_idx as a member of block can reduce unnecessary time and system resource comsumption of dev_idx mapping every time the block data writing to the dsp.
I am sorry, but I don't understand what this means. Can you please elaborate?
Also, can you please explain what the real issue is? (My first guess when seeing the error message before was that a signed integer is truncated to an unsigned char or so, but I couldn't see immediately where that is happening)
Sorry to late feedback. I had been troubled by this issue for several weeks. At first, I also think it would one of variables overflow, according to the compiling error message. However, after investigation, no result came out. In fact, compiler will report the line number where the variable overflow is, if there was risk on the variable overflow. Yet, this compiling error did not report any line number. Finally, I didn’t realize that it would be the code section overflow until that compiling error message magically disappeared, one day I removed some functions in the tas2781-fwlib.c. So, I began to simplify some functions in the code.
I managed to reproduce the issue with the m68k cross-compiler from https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/13.2.0/
| sound/soc/codecs/tas2781-fmwlib.c:779: switch (block->type) { subq.l #1,%a0 |, tmp56 moveq #36,%d0 |, cmp.l %a0,%d0 | tmp56, jcs .L122 | move.l %a0,%d0 | tmp56, tmp59 add.l %d0,%d0 | tmp59 move.w .L95(%pc,%d0.l),%d0 |, tmp60 .L125: | sound/soc/codecs/tas2781-fmwlib.c:827: switch (block->type) { jmp %pc@(2,%d0:w) | tmp66 .balignw 2,0x284c .L95: .word .L109-.L95 .word .L113-.L95
[...]
| sound/soc/codecs/tas2781-fmwlib.c:827: switch (block->type) { moveq #36,%d0 |, cmp.l %a0,%d0 | tmp77, jcs .L122 | move.l %a0,%d0 | tmp77, add.l %d0,%d0 | move.l %d0,%a0 |, tmp65 ---> move.w .L95(%pc,%a0.l),%d0 |, tmp66 jra .L125 |
Looks like the compiler is sharing the jump table at L95 for two different switch() statements, but the PC-relative offset to refer to the table is too large when using -m68000. It works fine with -m68020.
Probably a compiler bug?
Signed-off-by: Shenghao Ding shenghao-ding@ti.com
Changes in v1:
- | Reported-by: kernel test robot lkp@intel.com | Closes: | https://lore.kernel.org/oe-kbuild-all/202309222048.RnSqEIK5-lkp@intel.com/
Gr{oetje,eeting}s,
Geert