Do FDPP kernel debug printf messages end up in the Dosemu log?

[andrewbird]

I want to do a little work on fdpp and I need to turn on the printf debugging messages from the kernel. Do they end up in the kernel log file (I added log option f, but don't see the printf style messages)? I did search both fdpp and dosemu issues/PR and the wiki, but I couldn't find it. I can't believe I never wanted this before.

[stsp]

dosemu -D9+f and in the log:

fdpp: System call (21h): 3d00
fdpp: dispatch blk_driver
fdpp: dispatch blk_driver done
fdpp: dispatch blk_driver
fdpp: dispatch blk_driver done
fdpp: dispatch blk_driver
fdpp: dispatch blk_driver done
fdpp: dispatch int21_service done
fdpp: Reading FDPPCONF.SYS...
fdpp: dispatch int21_service
fdpp: System call (21h): 3f49
fdpp: dispatch blk_driver

[andrewbird]

I'm still not getting everything, for example I don't see 'CDS entry' etc

[stsp]

See hdr/debug.h for a particular printf.
You need DEBUG macro, and maybe
something custom for your particular
printf.

[andrewbird]

Still struggling with this. I added

diff --git a/fdpp/meson.build b/fdpp/meson.build
index 7366f66f..01e3e4a2 100644
--- a/fdpp/meson.build
+++ b/fdpp/meson.build
@@ -174,7 +174,7 @@ if get_option('buildtype').startswith('debug')
 else
   DEBUG_OPTS = []
 endif
-CXX_ARGS = ['-DFDPP', '-DDEBUG', '-DWITHFAT32',
+CXX_ARGS = ['-DFDPP', '-DDEBUG', '-DDEBUG_TRUENAME', '-DDOSEMU', '-DWITHFAT32',
       '-fno-threadsafe-statics',
       '-Wno-address-of-packed-member', DEBUG_OPTS]
 LD_ARGS = []
diff --git a/kernel/newstuff.c b/kernel/newstuff.c
index 0b5da4d3..90c4538f 100644
--- a/kernel/newstuff.c
+++ b/kernel/newstuff.c
@@ -267,6 +267,8 @@ COUNT truename(__XFAR(const char) src, char FAR *dest, COUNT mode)
   char FAR *rootPos;
   char src0;
 
+  tn_printf(("truename(%s)\n", "HOLA"));
+
   tn_printf(("truename(%s)\n", GET_PTR(src)));
 
   /* First, adjust the source pointer */
@@ -320,8 +322,8 @@ COUNT truename(__XFAR(const char) src, char FAR *dest, COUNT mode)
   }
 
   fmemcpy(&TempCDS, cdsEntry, sizeof(struct cds));
-  tn_printf(("CDS entry: #%u @%P (%u) '%s'\n", result, GET_FP32(cdsEntry),
-            TempCDS.cdsBackslashOffset, GET_FP32(TempCDS.cdsCurrentPath)));
+  //tn_printf(("CDS entry: #%u @%P (%u) '%s'\n", result, GET_FP32(cdsEntry),
+  //          TempCDS.cdsBackslashOffset, GET_FP32(TempCDS.cdsCurrentPath)));
   /* is the current_ldt thing necessary for compatibly??
      -- 2001/09/03 ska*/
   current_ldt = cdsEntry;
@@ -429,7 +431,8 @@ COUNT truename(__XFAR(const char) src, char FAR *dest, COUNT mode)
 
     if (!(mode & CDS_MODE_SKIP_PHYSICAL))
     {
-      tn_printf(("SUBSTing from: %s\n", cp));
+      //tn_printf(("SUBSTing from: %s\n", cp));
+
 /* What to do now: the logical drive letter will be replaced by the hidden
    portion of the associated path. This is necessary for NETWORK and
    SUBST drives. For local drives it should not harm.

I know it's compiling because I had to comment out some mismatch pointer types.

and called dosemu with this

LOG_LEVEL="-D9+fd"
DSP="-td"

bin/dosemu  \
        -n ${DSP} -f test-imagedir/dosemu.conf ${LOG_LEVEL} -o test.log \
        --Fimagedir `pwd`/test-imagedir $*

fdpp: dispatch int21_service
fdpp: System call (21h): 3f39
fdpp: dispatch int21_service done
fdpp: dispatch int21_service
fdpp: System call (21h): 3f39
fdpp: dispatch int21_service done
fdpp: dispatch int21_service
fdpp: System call (21h): 3f39
fdpp: dispatch int21_service done
fdpp: dispatch int21_service
fdpp: System call (21h): 3f39
fdpp: dispatch int21_service done
fdpp: dispatch int21_service
fdpp: System call (21h): 3f39
fdpp: dispatch int21_service done
fdpp: CONFIG=[CHAIN=@confhook.sys]
fdpp: dispatch int21_service
fdpp: System call (21h): 6c00
MFS: Entering dos_fs_redirect, FN=23, 'Qualify filename'
MFS: selecting drive
MFS: select_drive() DS:SI = 'confhook.sys'
MFS: selected drive 2: /tmp/test-imagedir/dXXXXs/c/
MFS: is_msdos_device confhook
MFS: dos_fs_redirect unhandled, failing
MFS: Entering dos_fs_redirect, FN=2E, 'Multipurpose open'
MFS: selecting drive
MFS: select_drive() sda_filename1 = 'C:\CONFHOOK.SYS'
MFS: selected drive 2: /tmp/test-imagedir/dXXXXs/c/
MFS: Multipurpose open file: C:\CONFHOOK.SYS
MFS: Mode, action, attr = 0, 0, 20
MFS: dos_fs: build_ufs_path for DOS path 'C:\CONFHOOK.SYS'
MFS: dos_gen: ufs '/tmp/test-imagedir/dXXXXs/c/', path '\CONFHOOK.SYS', l=28
MFS: dos_gen: path_to_ufs '/tmp/test-imagedir/dXXXXs/c//confhook.sys'
MFS: dos_fs: build_ufs_path result is '/tmp/test-imagedir/dXXXXs/c/confhook.sys'
MFS: find file /tmp/test-imagedir/dXXXXs/c/confhook.sys
MFS: is_msdos_device /tmp/test-imagedir/dXXXXs/c/confhook.sys
MFS: scan_dir(/tmp/test-imagedir/dXXXXs/c,confhook.sys)
MFS: scan_dir gave confhook.sys FALSE
MFS: find_file(): no match: /tmp/test-imagedir/dXXXXs/c/confhook.sys
MFS: dos_fs_redirect failed
fdpp: dispatch int21_service done
fdpp: dispatch int21_service
fdpp: System call (21h): 3f39
fdpp: dispatch int21_service done
fdpp: CONFIG=[]

I expected to see 'HOLA' in the log before the 'Qualify_Filename'. Just as a test I removed my dosemu2 and fdpp packages to ensure the global fdpp library wasn't being found (even though I can see '- GIT' in the log) and also rebuilt dosemu2 after building fdpp.

[stsp]

Try fdloudprintf()

[andrewbird]

I added fdloudprintf("truename(%s)\n", "ADIOS"); still nothing.

[andrewbird]

How can I tell which libfdpp.so is being used?

[stsp]

$ ldd libplugin_fdpp.so
linux-vdso.so.1 (0x0000773f792c4000)
libfdpp.so.35 => /usr/local/lib/libfdpp.so.35 (0x0000773f79145000)
libfdldr.so.35 => /usr/local/lib/libfdldr.so.35 (0x0000773f79140000)

[andrewbird]

and now

ajb@calypso:/clients/common/dosemu2.git$ ldd ./2.0-pre9/bin/libplugin_fdpp.so
	linux-vdso.so.1 (0x00007605d6915000)
	libfdpp.so.35 => not found
	libfdldr.so.35 => not found
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007605d6600000)
	/lib64/ld-linux-x86-64.so.2 (0x00007605d6917000)

[andrewbird]

So just tried dosemu2, it exits now says can't find fdpp. Will rebuild and see if it now finds the right one.

[andrewbird]

Recompile made no difference.

However if I set export LD_LIBRARY_PATH="/clients/common/fdpp.git/inst" the boot proceeds further, but ultimately stops at

fatfs: full_name: "/tmp/test-imagedir/dXXXXs/c/fdppconf.sys"
failed to open /clients/common/fdpp.git/inst/share/fdpp/fdppkrnl.35.10.elf
ERROR: FDPP boot failed

Got to go out now.

[andrewbird]

Seems I have to set LD_LIBRARY_PATH and use the dosemu -p arg just to boot if I want to use FDPP with a non standard installation directory now.

[andrewbird]

The original problem was solved with -D9+f as you said right at the beginning, but the FDPP was in a non standard install path and the global library was used instead.

[stsp]

Seems I have to set LD_LIBRARY_PATH

Either that, or configure dosemu
for non-std location. It always was
like that.

[andrewbird]

It already is (as above)

FDPP_LIBRARY_SOURCE="/clients/common/fdpp.git"
export PKG_CONFIG_PATH=${FDPP_LIBRARY_SOURCE}/inst/lib/pkgconfig
./default-configure -d \
        --with-fdpp-lib-dir=${FDPP_LIBRARY_SOURCE}/inst/lib/fdpp \
        --with-fdpp-kernel-dir=${FDPP_LIBRARY_SOURCE}/inst/share/fdpp \
        --with-fdpp-include-dir=${FDPP_LIBRARY_SOURCE}/inst/include \
        --with-fdpp-pkgconf-dir=${FDPP_LIBRARY_SOURCE}/inst/lib/pkgconfig

Or is there something else I need to do?

[stsp]

Maybe there is something less
you need to do. For me this works:

./default-configure -d --with-fdpp-lib-dir=/home/stas/src/fdpp/fdpp/build --with-fdpp-include-dir=/home/stas/src/fdpp/include --with-fdpp-kernel-dir=/home/stas/src/fdpp/fdpp/build

[andrewbird]

So is /home/stas/src/fdpp/ your repo or /home/stas/src/fdpp/fdpp? Do you still need to make install fdpp now?

[stsp]

fdpp/fdpp is a build dir.
I don't need to make install.

[andrewbird]

Can you share your ./configure.meson and the meson commands for fdpp?

[stsp]

I built with make.
With meson I suppose installing
is more friendly than to search
its internal dirs.

[andrewbird]

okay, switched to make, but I don't get a fdpp/build directory. How do I tell it to do out of tree build?

[stsp]

mkdir build
cd build
../configure
make -j 9

[andrewbird]

Thanks, I have it working now with make and no LD_LIBRARY_PATH required. Wow, talk about going down a rabbit hole!

[stsp]

I still don't know why it won't
work the same way if you install
it with meson to some /home prefix.
LD_LIBRARY_PATH should also
work, but you may need to
additionally specify FDPP_KERNEL_DIR.

[andrewbird]

For a bit of fun I just added this to the bottom of dosemu's fdpp plugin, it logs the path of the actual FDPP library that was loaded.
What do you think, worth tidying up and including?

FDPP kernel "- GIT "
Path to FDPP: /clients/common/fdpp.git/build/fdpp/libfdpp.so.35

diff --git a/src/plugin/fdpp/fdpp.c b/src/plugin/fdpp/fdpp.c
index e1b546072..7faffb404 100644
--- a/src/plugin/fdpp/fdpp.c
+++ b/src/plugin/fdpp/fdpp.c
@@ -22,6 +22,7 @@
 #include <assert.h>
 #include <stdio.h>
 #include <fdpp/thunks.h>
+#include <dlfcn.h>
 #if FDPP_API_VER < 35
 #error wrong fdpp version
 #endif
@@ -229,4 +230,11 @@ CONSTRUCTOR(static void init(void))
 #ifdef FDPP_KERNEL_DIR
     permit_dir_ro(FDPP_KERNEL_DIR);
 #endif
+
+    {
+        Dl_info info;
+        if (dladdr((void*)FdppInit, &info)) {
+            dbug_printf("Path to FDPP: %s\n", info.dli_fname);
+        }
+    }

[stsp]

You'd need configure checks, as
this code is unportable.
Also while I have nothing against
a better logging, the mere ldd
does essentially the same thing.
It doesn't lie: even if you set
LD_LIBRARY_PATH, ldd will reflect
the change.

[andrewbird]

You don't use rpath then?

[stsp]

If rpath is used (when the
non-default location is configured),
ldd also reflects that. It does not lie.

[andrewbird]

Okay, then not required, no worries.

[andrewbird]

After enabling some debug printfs, I get compilation errors with DebugPrintf(("Remote Find: n='%Fs\n", PriPathName));. How do I print a far string?

[stsp]

DebugPrintf(("MEMDISK args:{%s}\n", GET_PTR(mdsk->cmdline)));

[andrewbird]

That's interesting, it led me to FarPtr.get_ptr(), from there I added a .get_str_segoff() to return the "XXXX:YYYY" segoff. What tool converts dosfns.c into dosfns.cc, as I'd like to see if I can hack up changing the printf style "%Fs" and "%Fp" into "%s" and massage the arguments to leave the C source unchanged?

[stsp]

The tool is mkfar.sh.
However there is a prf.c that
is responsible for printf formats,
I don't think you need to tweak
any script.

[andrewbird]

OOh, that's interesting! Thanks! BTW every time I start fiddling with FDPP(fix some DOS bug) I seem to go down a C++ rabbit hole, it's very interesting but probably a little late to start learning it properly now.

[stsp]

I bet.
These days its much better to
invest the time into pyTorch, Kerras
and alike things... I regret that was
studying the wrong things, but at
least now we have to learn Rust.

[andrewbird]

In order to use va_args() I need the type. I was hoping the ancestor of FarPtr would be non templated but it seems not. I'm sure this is very hacky, but seems to work.

diff --git a/kernel/prf.c b/kernel/prf.c
index 72ec5d87..f4702e7d 100644
--- a/kernel/prf.c
+++ b/kernel/prf.c
@@ -312,11 +312,20 @@ STATIC int printf_handle_char(CONST BYTE ** _fmt, va_list *_arg)
 
       case 'P':
         {
+#ifdef FDPP
+          FarPtr<char> *obj_ptr = (FarPtr<char> *)va_arg(arg, void *);
+
+          char SSFAR *tmp = charp;
+          p = (char *)obj_ptr->get_str_segoff();
+          charp = tmp;
+
+#else
           UDWORD w0 = va_arg(arg, unsigned);
           char SSFAR *tmp = charp;
           _sprintf(s, "%04x:%04x", w0 >> 16, w0 & 0xffff);
           p = s;
           charp = tmp;
+#endif
           break;
         }

 #if defined(DEBUG_FIND)
-  DebugPrintf(("Remote Find: n='%Fs\n", PriPathName));
+  DebugPrintf(("Remote Find: n='%P'\n", PriPathName));
+  DebugPrintf(("Remote Find: n='%s'\n", PriPathName.get_ptr()));
 #endif

fdpp: Remote Find: n='F997:03BE'
fdpp: Remote Find: n='C:\FDPPAUTO.BAT'

[stsp]

What didn't work?
#define MCBDESTRY(p) (fdebug("MCB corruption, bad:%P\n",
GET_FAR(p)),_fail(),DE_MCBDESTRY)

[andrewbird]

Didn't try it with %P, just assumed it was broken.

[andrewbird]

Just doing a clean-up, making sure that when I enable various DEBUG options we can still compile.

Any reason why DEBUG_PRINT_COMPORT and the corresponding 'dbgc_printf' should still exist? I checked the FreeDOS kernel the code behind it was in assembly, and as far as I can see was removed in FDPP. If DEBUG_PRINT_COMPORT is defined then in dosemu I have a missing symbol with mangled name of 'dbgc_printf'.

[stsp]

I don't think it was removed.
It more looks like it was unfinished
in freedos itself, when forked.

[andrewbird]

Next question DosUpFMem() is printing crap to the log instead of a single character

fdpp: NLS: DosUpFMem(): len=1, f997:1344="fdpp: Afdpp: "

[andrewbird]

Perhaps a clue is the correct single character is the 'A' towards the middle of the string. Not sure how a printf("%c)" can print larger than a single char.

[stsp]

Same silly code is in freedos.
Not sure why they though that
log() and printf() is the same
thing, but they did.