search for: debug_port

BTRFS file systems will be corrupted on 6.02 (mainstream) and some previous versions. DYNAMIC_DEBUG makes the core larger than the allowed. Even before its introduction, building Syslinux with DEBUG_PORT enabled would probably corrupt BTRFS images (IIRC) *if* ldlinux.sys surpasses the maximum allowed size. Besides, the installer isn't safe at all... The check could be easily made there to avoid overwriting BTRFS superblocks. It simply install ldlinux.sys blindly even when it could be done othe...

This patch adds support for printing messages through a debug console. QEMU, for example, supports this through the debugcon facility. The benefit is that it's *much* faster than printing over a serial port. To print to I/O port 0x402 (the default used by SeaBIOS and OVMF), add "-DDEBUG_IO_PORT=0x402 -DCORE_DEBUG=1" to the build CFLAGS. To enable a debug console in QEMU that

On 05-08-15 12:05, Gene Cumm wrote: > > I recompiled with this in mk/devel.mk <http://devel.mk>: > > GCCWARN += -DDEBUG_PORT=0x2f8 -DCORE_DEBUG=1 > > 0x2f8 is a BIOSism. Is this a problem? The example in the comments said 0x3f8 which is COM1.

I noticed several issues when diagnosing why pxechn.c32 didn't work in 5.01-pre3. 1) pxechn.c32, prdhcp.c32 and other modules crash Syslinux and force a reboot by executing an unresolved symbols. unload_pxe(), dns_resolv() and pxe_call() are the three. "Error: An undefined symbol was referenced" 2) In past versions, I built a debug build by having "CFLAGS += -DDEBUG=1"

On 05-08-15 15:28, Gene Cumm wrote: >>> 0x2f8 is a BIOSism. > >> Is this a problem? The example in the comments said 0x3f8 which is COM1. > > It means that a BIOS IO port for a UART won't work for EFI. No value > for DEBUG_PORT will do anything unless someone's got some translation > "glue" to take the attempts to open the UART and use an EFI handle > instead. That's weird, since enabling this finally got me some debugging output from dprintf(). I think I'm being lucky here! HP apparently pr...

On Wed, Aug 5, 2015 at 8:06 AM, Oscar Roozen <oscar.roozen at brightcomputing.com> wrote: > On 05-08-15 12:05, Gene Cumm wrote: >> >> > I recompiled with this in mk/devel.mk <http://devel.mk>: >> > GCCWARN += -DDEBUG_PORT=0x2f8 -DCORE_DEBUG=1 >> >> 0x2f8 is a BIOSism. > Is this a problem? The example in the comments said 0x3f8 which is COM1. It means that a BIOS IO port for a UART won't work for EFI. No value for DEBUG_PORT will do anything unless someone's got some translation "glue&q...

On Fri, Jul 12, 2013 at 2:21 AM, H. Peter Anvin <hpa at zytor.com> wrote: > On 07/11/2013 10:16 PM, Raphael S.Carvalho wrote: >> This patch adds support for serial output functions. >> It may be useful for debugging purposes since you can separate ordinary outputs from debugging dumps. >> Just add "serial.h", and use either serial_print or serial_puts as you

...linux/core/lwip/src/include/ipv4 -I/root/syslinux/core/fs/pxe -D__SYSLINUX_CORE__ -D__FIRMWARE_BIOS__ -I/root/syslinux/bios -DLDLINUX=\"ldlinux.c32\" -c -o kaboom.o /root/syslinux/core/kaboom.c So the CORE_DEBUG option is passed, and in the code I see: #if defined(CORE_DEBUG) || defined(DEBUG_PORT) #include <dprintf.h> __export __noreturn __bad_SEG(const volatile void *p) { dprintf("SEG() passed an invalid pointer: %p\n", p); kaboom(); } #endif So IIUC it should include that function if CORE_DEBUG is set to 1 no ? However: # nm ./bios/core/kaboom.o U cal...

>>> > On 05-08-15 12:05, Gene Cumm wrote: >> >>? > I recompiled with this in mk/devel.mk <http://devel.mk>: >>? >? GCCWARN += -DDEBUG_PORT=0x2f8 -DCORE_DEBUG=1 >> >> 0x2f8 is a BIOSism. > Is this a problem? The example in the comments said 0x3f8 which is COM1. It means that a BIOS IO port for a UART won't work for EFI.? No value for DEBUG_PORT will do anything unless someone's got some translation &qu...

...: > GCCWARN += -Wno-clobbered -DCORE_DEBUG=1 -DDEBUG_MALLOC -DDEBUG_THREAD > And removing the -DDYNAMIC_DEBUG but now syslinux doesn't want to build: MALLOC and THREAD are two debugs you probably don't want. If you can capture the serial port and the firmware would allow it, "-DDEBUG_PORT=0x3f8" would direct output to the first serial port. "-DDEBUG_STDIO" may be useful but by the looks of it, not until after ldlinux.* is loaded as printf()'s code isn't in the core but ldlinux.*. > ranlib liblpxelinux.a > ld -m elf_i386 -Bsymbolic -pie -E --hash-style...

On Tue, May 20, 2014 at 12:20 PM, Anatol Pomozov <anatol.pomozov at gmail.com> wrote: > Hi > > On Tue, May 20, 2014 at 9:18 AM, Anatol Pomozov > <anatol.pomozov at gmail.com> wrote: >> Hi >> >> On Tue, May 20, 2014 at 3:12 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >>> On May 20, 2014 12:33 AM, "Anatol Pomozov"

...ble. Some remain, but not many (and eventually they'll be gone too). There's also a patch to make better use of ld's --as-needed option and various other bug fixes/cleanups. The following changes since commit ff7334a2ce536b7f4b1f6d6f93ff4e285a3bd45a: Only compile dprintf/vdprintf if DEBUG_PORT is defined (2012-07-19 08:42:32 -0700) are available in the git repository at: git://git.zytor.com/users/mfleming/syslinux.git elflink Matt Fleming (9): core/elflink: Delete ADV code that's already in ldlinux ldlinux: Stop using the internal KT_* image types lib/sys/module...