[coreboot] Re: GDB stub & bootblock dependencies (CONFIG_IDT_IN_EVERY_STAGE=y)

[Zeh, Werner]

Hi Jan.

The problem here is that the needed functions for GDB in console are not included in bootblock. In src/console/console.c you can see:

#if CONFIG(GDB_STUB) && (ENV_ROMSTAGE || ENV_RAMSTAGE)
void gdb_hw_init(void)
{
        __gdb_hw_init();
}

void gdb_tx_byte(unsigned char byte)
{
        __gdb_tx_byte(byte);
}

void gdb_tx_flush(void)
{
        __gdb_tx_flush();
}

unsigned char gdb_rx_byte(void)
{
        return __gdb_rx_byte();
}
#endif

In order to overcome this please give the attached patch a try. At least on my side it is able to compile with that patch.
What I am currently not sure about are the static buffers and how they will work in bootblock

Werner
> -----Original Message-----
> From: Samek, Jan 
> Sent: Thursday, July 22, 2021 6:15 PM
> To: [e-mail]
> Cc: Zeh, Werner 
> Subject: GDB stub & bootblock dependencies (CONFIG_IDT_IN_EVERY_STAGE=y)
>
> Hello,
>
> I am currently developing on Intel TGLRVP-UP3, but this should be relevant for
> other TGL-based platforms and possibly all other that set
> CONFIG_IDT_IN_EVERY_STAGE=y:
>
> When I try to use the GDB stub for my debug attempts on TGL
> (CONFIG_GDB_STUB=y), I get the following 'undefined reference' errors during
> the bootblock linkage process:
>
> src/arch/x86/exception.c:225: undefined reference to `gdb_tx_byte'
> src/arch/x86/exception.c:225: undefined reference to `gdb_tx_byte'
> src/arch/x86/exception.c:225: undefined reference to `gdb_tx_byte'
> src/arch/x86/exception.c:230: undefined reference to `gdb_tx_flush'
> src/arch/x86/exception.c:230: undefined reference to `gdb_tx_flush'
> src/arch/x86/exception.c:230: undefined reference to `gdb_tx_flush'
> src/arch/x86/exception.c:235: undefined reference to `gdb_rx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:225: undefined
> reference to `gdb_tx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:225: undefined
> reference to `gdb_tx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:225: undefined
> reference to `gdb_tx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:225: undefined
> reference to `gdb_tx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:235: undefined
> reference to `gdb_rx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:235: undefined
> reference to `gdb_rx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:235: undefined
> reference to `gdb_rx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:235: undefined
> reference to `gdb_rx_byte'
>
> The gdb_*() functions used in exception.c are defined in src/console/console.c.
> Nevertheless, the problem with the functions in question is that they're defined
> under '#if CONFIG(GDB_STUB) && (ENV_ROMSTAGE || ENV_RAMSTAGE)' which
> obviously doesn't allow them to be compiled into the bootblock code while
> they're unconditionally (there's only the IDT_IN_EVERY_STAGE condition)
> referenced in exception.c
>
> Looking at src/arch/x86/Makefile.inc (filtering out only the lines of interest), it's
> apparent that exception.c is linked in all stages when the IDT_IN_EVERY_STAGE
> option is set:
>
> 76:  bootblock-$(CONFIG_IDT_IN_EVERY_STAGE) += exception.c
> 111: verstage-$(CONFIG_IDT_IN_EVERY_STAGE) += exception.c
> 148: romstage-$(CONFIG_IDT_IN_EVERY_STAGE) += exception.c
> 187: postcar-$(CONFIG_IDT_IN_EVERY_STAGE) += exception.c
> 229: ramstage-y += exception.c
> 291: smm-$(CONFIG_IDT_IN_EVERY_STAGE) += exception.c
>
> The behavior appears in revision
> b90aba43c1405d3d2cb7cba05e68906e979dcda3 (master).
>
> To reproduce,
> run 'make menuconfig',
> select 'Mainboard ->Mainboard Vendor': 'Intel',
> select 'Mainboard -> Mainboard Model': 'Tiger Lake UP3 RVP',
> select 'Debugging -> GDB debugging support': 'y'.
> run 'make'.
>
> What do you think would be the best approach to make the GDB stub work on
> these platforms?
>
> P.S. My bug tracker registration is currently pending an approval, I could be able
> to create a ticket afterwards.
>
> Regards,
> Jan