Dear Genodians,
I am currently porting the emmc driver from the compulab's Linux source tree [1].
[1] https://github.com/compulab-yokneam/meta-bsp-imx8mm/blob/iot-gate-imx8_r3.0/...
Everything went more or less smoothly until I got to this assembler error:
```
/tmp/ccOLpMJW.s: Assembler messages: /tmp/ccOLpMJW.s:987: Error: section name '__irqchip_of_table' already defined as another symbol ```
This error message indicates a rather obvious error: It seems the symbol with that name is defined twice with different 'type' in different compilation units.
However, when using grep I can find the symbol within `repos/dde_linux/src/lib/lx_emul/spec/arm/irqchip.c` but it is not that clear within the Linux source where it is defined. I assume in a linker script but I'm not sure at all. I couldn't find it using grep (not event a declaration, maybe some macro magic happen here). Which let me think that the error might not be due to what I actually think...
I tried with nm & grep on each generated object in the build directory, but couldn't find the culprit either.
I wonder if someone has some experience with dde_linux, whom may have some idea of what could be the causes? Or what I can try to debug it harder...
PS: I am aware that some parts of the lx_emul layer may not work with this source tree, as it has a different version (5.10.72) from the one in use by dde_linux. I expect to have some trouble with this at some point, maybe this is the case already?
Many thanks for reading me!
Cheers, Jean-Adrien
Hello Jean-Adrien,
I'm not an expert with dde_linux for ARM, but the genode-zynq repo [1] also uses a Linux 5.10 derivate from Xilinx [2]. Maybe you can find a hint how to tackle this issue there? The xilinx_linux port also includes the symbol.
grep -rn __irqchip_of_table contrib/xilinx_linux-83ebf9354e4a56e442a5e63324e0b782150dc87f/src/linux/
contrib/xilinx_linux-83ebf9354e4a56e442a5e63324e0b782150dc87f/src/linux/drivers/irqchip/irqchip.c:33:irqchip_of_match_end __used __section("__irqchip_of_table_end"); contrib/xilinx_linux-83ebf9354e4a56e442a5e63324e0b782150dc87f/src/linux/drivers/irqchip/irqchip.c:35:extern struct of_device_id __irqchip_of_table[]; contrib/xilinx_linux-83ebf9354e4a56e442a5e63324e0b782150dc87f/src/linux/drivers/irqchip/irqchip.c:39: of_irq_init(__irqchip_of_table);
and genode-zynq uses this file in its SD card driver.
grep -rn irqchip repos/zynq/
repos/zynq/src/drivers/sd_card/zynq/source.list:18:drivers/irqchip/irqchip.c
[1] https://github.com/genodelabs/genode-zynq/blob/master/ports/xilinx_linux.por... [2] https://github.com/Xilinx/linux-xlnx/blob/xilinx-v2021.2
Happy hacking
Hi Jean-Adrien,
On Wed, 21 Sep 2022 07:55:21 +0200 Christian Helmuth christian.helmuth@genode-labs.com wrote:
I'm not an expert with dde_linux for ARM, but the genode-zynq repo [1] also uses a Linux 5.10 derivate from Xilinx [2]. Maybe you can find a hint how to tackle this issue there? The xilinx_linux port also includes the symbol.
The zynq SD card driver actually uses Genode's linux port (5.14). At some point I moved to this version to avoid maintaining another linux version in dde_linux. I kept the xilinx_linux port as a backup and forgot to remove it once the SD card driver was finished.
King regards Johannes
Hello Jean-Adrien,
On Tue, Sep 20, 2022 at 05:41:50PM +0200, Jean-Adrien Domage wrote:
/tmp/ccOLpMJW.s: Assembler messages: /tmp/ccOLpMJW.s:987: Error: section name '__irqchip_of_table' already defined as another symbol
This error message indicates a rather obvious error: It seems the symbol with that name is defined twice with different 'type' in different compilation units. However, when using grep I can find the symbol within `repos/dde_linux/src/lib/lx_emul/spec/arm/irqchip.c` but it is not that clear within the Linux source where it is defined. I assume in a linker script but I'm not sure at all. I couldn't find it using grep (not event a declaration, maybe some macro magic happen here). Which let me think that the error might not be due to what I actually think...
In general, you might find the compilation unit that already contains the symbol of the Linux kernel by applying `find` to all object files of your target, and by combining `nm` and `grep` to find the locations. You can use the flag `--print-file-name` when calling `nm` to include the corresponding filename in every match.
In the concrete case, I assume it is a combination of macros, like `IRQCHIP_DECLARE`, and the ones it depends on. Probably you've included a Linux kernel source file with interrupt controller definitions, which is in most cases not a good idea.
Best regards Stefan
Le 2022-09-21 08:18, Stefan Kalkowski a écrit :
Hello Jean-Adrien,
On Tue, Sep 20, 2022 at 05:41:50PM +0200, Jean-Adrien Domage wrote:
/tmp/ccOLpMJW.s: Assembler messages: /tmp/ccOLpMJW.s:987: Error: section name '__irqchip_of_table' already defined as another symbol
This error message indicates a rather obvious error: It seems the symbol with that name is defined twice with different 'type' in different compilation units. However, when using grep I can find the symbol within `repos/dde_linux/src/lib/lx_emul/spec/arm/irqchip.c` but it is not that clear within the Linux source where it is defined. I assume in a linker script but I'm not sure at all. I couldn't find it using grep (not event a declaration, maybe some macro magic happen here). Which let me think that the error might not be due to what I actually think...In general, you might find the compilation unit that already contains the symbol of the Linux kernel by applying `find` to all object files of your target, and by combining `nm` and `grep` to find the locations. You can use the flag `--print-file-name` when calling `nm` to include the corresponding filename in every match.
In the concrete case, I assume it is a combination of macros, like `IRQCHIP_DECLARE`, and the ones it depends on. Probably you've included a Linux kernel source file with interrupt controller definitions, which is in most cases not a good idea.
Best regards Stefan
Dear Genodians,
Thank you, everyone! I appreciate all of your answers! I'm now able to compile everything with dummies, without assembler errors. Here is my story:
I tried with nm and grep on each generated object in the build directory but couldn't find the culprit either.
I couldn't find the symbol with nm & grep before, as I followed the article from Stefan [1]. I shot myself in the foot because I forgot to remove `...| grep -i " t " |...` from the command line. Then I proceeded by eliminating every file referencing `__irqchip_of_table` which as led me to `repos/dde_linux/src/lib/lx_emul/spec/arm/irqchip.c` again.
[1] https://genodians.org/skalk/2021-04-08-dde-linux-experiments-1
With your help, I finally figured it out:
In the concrete case, I assume it is a combination of macros, like `IRQCHIP_DECLARE`, and the ones it depends on. Probably you've included a Linux kernel source file with interrupt controller definitions, which is in most cases not a good idea.
1. As suggested by Stefan, I paid attention not to do so. Only `lx_emul/../irqchip.c` made uses of `IRQCHIP_DECLARE`. To ensure that, commenting out this file from the `target.mk` made the error go away. But I do need it eventually.
2. I suspected a macro expansion from a Linux header to be the culprit. I added `CC_OPT += -S -save-temps=obj` to both `target.mk` of my mmc and sd_card drivers. The build may fail with lots of errors, but I can now compare the `irqchip.i` from mmc/ and sd_card/
The result for mmc is: ``` static const struct of_device_id __of_table_dde_gic_v3 ... __attribute__((__section__("__" "irqchip" "_of_table"))) __attribute__((__aligned__(__alignof__(struct of_device_id)))) = ... ``` Which is probably not what I want. Note how the attribute section is set `__section__("__" "irqchip" "_of_table")` which makes it not friendly to grep for.
For the sd_card driver, I obtain: ``` static void __of_declare_initcall_dde_irqchip_initdde_gic_v3(void)__attribute__((constructor)); static void __of_declare_initcall_dde_irqchip_initdde_gic_v3() { lx_emul_register_of_irqchip_initcall( ... ```
3. With our Linux source tree, something goes wrong when `IRQCHIP_DECLARE` expands. It does not result in an init_call registration, It turns out that `of.h` was missing from the shadow include path xD ...
Thank you very much!
Cheers, Jean-Adrien
--- Jean-Adrien Domage gapfruit AG Operating System Engineer
-
Christian Helmuth -
Jean-Adrien Domage -
Johannes Schlatow -
Stefan Kalkowski