32bit / 64bit GDB collision

Posted on by

So I’m trying to force a break in a program to look at the call stack.  Normally pretty easy stuff as far as adding breakpoints or the random i=j/0 type thing to force a div0 exception etc.

But I’ve been going crazy with this fun error:

gdb: unknown target exception 0x4000001f at 0x453b1c

And I should have checked my path earlier, as even though I’m using the 32bit version of GCC, the TDM-GCC project bundles their 32bit GDB as gdb32.exe .  Ouch.  The other hint of course was in the banner:

GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “x86_64-w64-mingw32”.

Yeah, further oops, in actually paying attention to how it executes:

(gdb) r
Starting program: C:\temp\dynamips\dynamips.exe -P 1700 -s 0:0:gen_eth:”\Device\NPF_{2F7A0E3F-0908-4489-8117-475A6AD299A6}” C1700-Y-.BIN -j
[New Thread 2696.0x22b0]
warning: `C:\WINDOWS\SYSTEM32\ntdll.dll’: Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `C:\WINDOWS\system32\wow64.dll’: Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `C:\WINDOWS\system32\wow64win.dll’: Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need “set solib-search-path” or “set sysroot”?
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need “set solib-search-path” or “set sysroot”?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need “set solib-search-path” or “set sysroot”?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need “set solib-search-path” or “set sysroot”?
warning: `C:\WINDOWS\system32\wow64cpu.dll’: Shared library architecture i386:x86-64 is not compatible with target architecture i386.
[New Thread 2696.0xabc]

Great.

So it’s not some exciting bug, but rather the 64bit version of gdb can kick off a 32bit exe, but it’ll get lost inside.  The proper 32bit GDB looks like this:

C:\temp\dynamips>gdb32.exe dynamips.exe
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “mingw32”.

And sure enough the call stack works fine.

Breakpoint 1, 0x00453b1c in mpc860_fec_set_nio ()
(gdb) bt
#0 0x00453b1c in mpc860_fec_set_nio ()
#1 0x004827e2 in dev_c1700_mb_eth_set_nio ()
#2 0x0044abdf in cisco_card_enable_all_nio ()
#3 0x0044b9df in vm_slot_enable_all_nio ()
#4 0x0044bb0e in vm_slot_init ()
#5 0x0044bb36 in vm_slot_init_all ()
#6 0x00481b5d in c1700_init_platform ()
#7 0x00481dc3 in c1700_init_instance ()
#8 0x004155b3 in vm_init_instance ()
#9 0x004125dc in main ()
(gdb)

Wasn’t that fun?!

8 thoughts on “32bit / 64bit GDB collision”

  1. Hi,

    Love your site by the way. It’s awesome. Went to send you a message and say your about neozeed, you must have grown up in Ontario too? Since those machines were only here…. Anyway, I spent some time (and much effort) getting Banyan Vines installed in QEMU, what a royal fucking pain in the ass that was, because the CDROM uses some custom format that I have no idea wtf, and the install program won’t recognize the drive (definitely looking for a specific device id). Turns out the “ISO” basically has a bunch of CPIO tape archives inside it, used a hexeditor to find the addresses and manually separate them. Then I directly hexedited the raw hard drive image after ascii searching the install script that started up after boot that said reboot to install cdrom and added /bin/sh; instead of sync;doreboot. Now I started attaching each tape drive image as a second hard drive, and directly extracting the cpio archive, sync and reboot until they were all done. Then I had to edit the install script to bypass extracting off the cdrom and continue install anyway, finally that worked! Only to find out the whole system is locked down by crazy serial number and option code systems (even flipping tcp/ip stuff has a code to enable). So I had to break out the IDA decompiler, and patch the stupid serial # system to accept fake crap, but it still got upset later because it said it was invalid. So I found some screenshots of an old running system, took the serial number off that and directly inserted it into the database…. Voila! So maybe you’re interested in a copy.

    Oh yeah, I was able to get networking working in it too, but not before I had patch the ne2k code in qemu because it didn’t work reliably at all. First issue was, most of the time it wouldn’t pass traffic properly because of a receive bug (Though it did work a couple times out of the blue). Second issue was the whole damn ne2k nic would stop working after ~1-2k packets. But it works reliably now! I’m not sure but I think you might have hit those bugs too from reading your pages…

    Len

    • dude, I’d LOVE a copy… I’ve always wanted to try Banyan. I’ve never used it, I’ve only heard about it as the inspiration for Active Directory, more so than Netware 4.x’s NDS.

      Yep, gerw up around Ontario, with the pain of what actually using QNX was like.. Never could understand why people would flock to a half baked wanna be UNIX, when there are so much better choices in the 21st century.

      Lucky you actually finding a serial #. That’s too funny.

      • http://mail.nrw.ca/banyan_qemu.rar

        VINES login is admin@NRW@NRW (their weird group/server names)
        Vines password is empty, just hit enter
        root password is root

        Inside the rar file there is the qemu boot args I used, and the two ne2k patch files if you need them. Oh and I patched the tcpip setup program to try and bypass the option code, if you need to use the original unpatched (if it exits), it’s in /disk1/banyan/comm/mtcpip.orig. Another note, if you use find, you have to add -print to the end.

          • Patches are against the latest qemu version. And yeah that’s where I got the ISO 🙂 You can see on that page though they never figured out how to get it installed. “Uncomplete version. Still fighting to make the CD or Floppy available after reboot of the 1st installation. ” I was actually thinking about trying to install the 8.6 patches you see there, but the 8.6 (and all other versions except 8.5) requires a dongle to work so I’d probably have to patch that somehow.

  2. Also to reboot it’s “doreboot -r -n” then halt “doreboot -h -n”, and sometimes qemu will say error booting from hard drive on startup. Restarting it again fixes it. It has a compiler too though I never quite figured out how to use it, and it seems to run other SysV3/4 binaries (mostly), tried to get gcc running on it from some old binaries i found. Almost worked too except cpp coredumped. Was going to get around to trying some binaries from interactive or xenix maybe.

  3. Len, do you still have the Banyan 8.5 files to make the install work. I have the 2 boot *.img and the 3 other *.img… install failing at the install/fullinstall – reboot.

Leave a Reply