17:48 <oldgalileo> Hi! I got pointed this way from #osdev. I'm trying to include EFI debug symbols in the Linux kernel. [CONFIG_DEBUG_EFI](https://elixir.bootlin.com/linux/v5.10.104/source/arch/arm64/kernel/efi-header.S#L103) but I'm honestly very lost as to how to actually go about including the symbols

17:50 <oldgalileo> With CONFIG_DEBUG_EFI enabled, I see the `efi_debug_table` in the ELF headers. Do I need to manually do copy in debug symbols from EDKII (I have the `.debug` files from a build)?

19:31 <mwalle> krzk: robher: regarding machine compatible strings, what if there is simply no vendor of a board, like if it is open hardware. are there any recommendations?

19:33 <robher> mwalle: Is there no organization/project behind the design?

19:42 <mwalle> robher: no it's actually my private little project. not saying i'll upstream the dts (yet?). i just have a hard time putting something where the vendor is supposed to be

19:43 <mwalle> robher: i mean, i could just come up with a name. but yeah, maybe you were aware of anybody doing something similar

20:24 <robher> mwalle: mwalle,foo-board?

20:25 <robher> mwalle: seriously, we can probably just omit any vendor.

20:32 <mwalle> robher: i was also thinking about 'compatible = "foobar", "oshw,deNNNN"', where "deNNNN" is the project number you'll get when you apply at oshw for that project. But not sure, that might ever pass your validation schema, because "foobar" doesn't have any (vendor) prefix which make it unambiguous

20:33 <robher> mwalle: Just "oshw,deNNNN" seems fine to me.

20:41 <mwalle> robher: ok

21:32 <oldgalileo> Hi! Don't have a BNC, so I'm repeating my question from earlier. Don't mean to spam:

21:32 <oldgalileo> I'm trying to include EFI debug symbols in the Linux kernel. [CONFIG_DEBUG_EFI](https://elixir.bootlin.com/linux/v5.10.104/source/arch/arm64/kernel/efi-header.S#L103) but I'm honestly very lost as to how to actually go about including the symbols

21:32 <oldgalileo> With CONFIG_DEBUG_EFI enabled, I see the `efi_debug_table` in the ELF headers. Do I need to manually do copy in debug symbols from EDKII (I have the `.debug` files from a build)?

21:47 <conchuod> ardb: Is probably the one that'd know that stuff best?

22:05 <oldgalileo> Honestly I might be too far out of my depth with the assembly there. I'm trying to understand it, and reading it I'd expect there to be an `.init.rodata` section in the vmlinux ELF headers but I don't see that section. Just the `efi_debug_table` in the `.init.data` section

22:21 <oldgalileo> As a bit of context, I'm debugging an EFI crash which happens when a TrustZone session is closed and a call is made to EFI at the same time.

22:24 <oldgalileo> It looks like this causes a crash in EFI that the Kernel is able to unwind. I have the PC and LR which are outside of the normal Kernel memory space. My thought was to use the PC + CONFIG_EFI_RUNTIME_MAP to figure out at least which Dxe the crash is happening in.

22:24 <oldgalileo> However CONFIG_EFI_RUNTIME_MAP isn't available on ARM. So that seems like a deadend too. I'm pretty out of my depth here and lost :/ If anyone could help, I'd buy them a beer (in person if in Berlin ;) )

22:34 <heat> you might have more luck posting this in the linux-efi ML

22:36 <oldgalileo> heat: Hi again! Is it normal to ask for beginner help? I feel embarrassed as I think I'm just missing some very straight forward step for debugging.

22:37 <heat> it's not beginner help, you're dealing with awful breakage across multiple layers xD

22:37 <heat> i don't think CONFIG_EFI_RUNTIME_MAP is getting you much, that exports the runtime map only, but *not* the corresponding efi modules (and you can't get them after you exit boot services i'm pretty sure)

22:40 <heat> as far as i understand, CONFIG_DEBUG_EFI only gets you more debug in case you crash in the efistub bit (before you EBS), but i haven't dabbled with PE debug stuff before and ard might know better

22:47 <oldgalileo> On the latter point, that makes sense. I couldn't find any magic that looked into `.init.rodata` for debug symbols.