dde_linux: trying to port the emmc for arm_v8a driver from linux

[Jean-Adrien Domage]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20220922/58b53395/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x31959A52.asc
Type: application/pgp-keys
Size: 2544 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20220922/58b53395/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20220922/58b53395/attachment.sig>