Undefined reference to __mcerr_of_table

[johnny96.young]

In the jetson Linux 35.1 source tree, a structure variable __mcerr_of_table is referenced but not defined. This failed the build.

ld: warning: orphan section __mcerr_of_table' from drivers/platform/tegra/mc/mcerr-t21.o’ being placed in section `__mcerr_of_table’

ld: warning: orphan section __mcerr_of_table' from drivers/platform/tegra/mc/mcerr-t18x.o’ being placed in section `__mcerr_of_table’

ld: warning: orphan section __mcerr_of_table' from drivers/platform/tegra/mc/mcerr-t19x.o’ being placed in section `__mcerr_of_table’

ld: ld: DWARF error: can’t find .debug_ranges section.

drivers/platform/tegra/mc/mcerr.o: in function `tegra_mcerr_init’:

mcerr.c:(.text+0x5ec): undefined reference to `__mcerr_of_table’

I took a look at the source of 35.3.1 which I think is the latest. But this variable is not defined either. I wonder this is why ?

Thanks!

[DaveYYY]

Hi,
did you make any changes to the kernel source code? What version of compiler toolchain do you use?
Looks like we haven’t encountered such issue.

[johnny96.young]

Every thing is from nvidia Jetson Linux 35.1. I searched the symbol __mcerr_of_tabel in the whole source tree, all I can find is below :

$ ls
cscope.out kernel-5.10 nvethernetrm nvgpu nvidia

$ cscope -dp5
find this C symbol: __mcerr_of_table

C symbol: __mcerr_of_table

File Function Line
0 drivers/platform/tegra/mc/mcerr.c 41 extern struct of_device_id __mcerr_of_table;
1 drivers/platform/tegra/mc/mcerr.c tegra_mcerr_init 194 const struct of_device_id *matches = &__mcerr_of_table;

Turns out, there is a reference to this symbol from the function tegra_mcerr_init(), but no definition is found.

[johnny96.young]

The source file mcerr.c is in the tegra/mc folder and this source is built or not depending on the configuration NV_TEGRA_MC. See this line in the tegra/Makefile

obj-$(CONFIG_NV_TEGRA_MC) += mc/

If this configuration is not set in your build, you will not see this error. Because I need this config, so I have this problem, I guess.

You can find who introduced this variable to mcerr.c via the git commit history info. If you can ask the engineer who made this commit, the answer would be quick.

Thanks!

[johnny96.young]

In a tegra orin which I previously updated to 5.10.104-rt63, I can find this __mcerr_of_table variable in the runtime kernel with the crash utility.

This is the structure layout :

crash> struct of_device_id
struct of_device_id {
char name[32];
char type[32];
char compatible[128];
const void *data;
}
SIZE: 200

This is the data in __mcerr_of_table :

crash> struct of_device_id __mcerr_of_table
struct of_device_id {
name = “\002\001\000\000$\000\000\000\v\002\000\000\000\000\000\000\064\334\001\000\000\000\000\000\002\001\000\000$\000\000”,
type = “y\v\001\000\000\000\000\000A\334\001\000\000\000\000\000\002\001\000\000$\000\000\000\355\003\000\000\000\000\000”,
compatible = “N\334\001\000\000\000\000\000\002\001\000\000$\000\000\000Jt\001\000\000\000\000\000a\334\001\000\000\000\000\000\002\001\000\000$\000\000\000@\245\000\000\000\000\000\000{\334\001\000\000\000\000\000\002\001\000\000$\000\000\000>\003\000\000\000\000\000\000\210\334\001\000\000\000\000\000\002\001\000\000$\000\000\000%,\000\000\000\000\000\000\225\334\001\000\000\000\000\000\002\001\000\000$\000\000\000\067Z\000\000\000\000\000\000\242\334\001\000\000\000\000”,
data = 0x2400000102
}

However, the data in this structure above doesn’t look like valid. However, the system is running ok. If I dumped out more items with “struct of_device_id __mcerr_of_table -c5”, it appeared none of the five look like valid structure.

So, the variable __mcerr_of_table should be defined somewhere. And my recent build missed that module. But I don’t know which one is.

My question remains where __mcerr_of_table is defined in the source tree.

[DaveYYY]

Hi,

can you share the full workflow for how to reproduce this error? Also the version of the compiler toolchain you are using. We can successfully generate object files under drivers/platform/tegra/mc after enabling CONFIG_NV_TEGRA_MC=y in the config file.

[johnny96.young]

Thanks for the response. I actually built on an Orin. So I didn’t use the Nvidia toolchain. I ever built successfully many time before. But after some changes including configurations, I started to see this problem. However, if I cross-compile the bits on another x86 machine with the toolchain I downloaded from the jetson website, I could see the same problem.

Actually, my question is about the variable __mcerr_of_table. I cannot find the place it is defined. Because you have the git repo of the source tree which I don’t have, so it should be quite easy for you to find out the commit-hash which introduced this code. You can do this way:

$ git blame -L41,+1 drivers/platform/tegra/mc/mcerr.c
or
$ git blame -L194,+1 drivers/platform/tegra/mc/mcerr.c

The ‘git blame’ command will display the commit-hash number. So you can find the patch and in this patch the definition will be found.

$git show commit-hash

The line number 41 or 194 and the places where __mcerr_of_table is referenced in the source.

Note: the line numbers may be different in your version of source tree. Use cscope to search __mcerr_of_table first.

Thanks!

[DaveYYY]

Hi,

Yeah, if you do need it, I will check our codebase and communicate with the guy who wrote the code.
But I don’t think it’s a problem as I also did it on the public BSP freshly downloaded from our website, not on our codebase. Can you elaborate under which circumstances do you fail to build the code (Jetson/x86 PC, toolchain version, L4T version, etc.)

[johnny96.young]

Thanks Dave.
As said, the problem is persistently reproducible in my build environment which is Jetson ORIN without toolchain + L4T 35.1. If I did cross-compile on x86 with toolchain, it was the same.

This might be caused by the bunch of configuration changes. But all I need to know is where the variable __mcerr_of_table is defined in the L4T-35.1 source tree so I can include it in.

[DaveYYY]

Hi,

I’ve checked it with our developer, and will update you given any progress on it. I actually searched for it, and it’s only declared as an extern variable, but not defined anywhere else.
Also, are you using the recommend toolchain version on x86 cross compiling? Can you give the latest 35.3.1 a try, which I managed to build successfully?

[johnny96.young]

Yes, I used the recommended toolchain when I built on x86. Right now we want to stick with 35.1. But I can try 35.3.1 when I have time.

[DaveYYY]

Hi @johnny96.young,

Looks like it’s indeed a bug. Our developer is working on fixing it.
I will visit you again given any updates.

[johnny96.young]

Appreciated! Please let me know when you get a solution.

[DaveYYY]

Hi @johnny96.young,

Sorry for the late reply.

May I know what’s the use case for building MC drivers as loadable modules?
As it’s already built into the kernel.

Like, based on it’s functionality, I’m not seeing any need of unloading it dynamically.