Errors when trying to connect to gdb-bridge.

[Tasos Sahanidis]

Attempting to connect to the gdb bridge with either ddd or gdb directly, results in the following:

makestuff/hdlmake/apps/makestuff/umdkv2/scripts$ ./ddd.sh 8000

GNU DDD 3.3.12 (x86_64-pc-linux-gnu), by Dorothea LIgnoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
/tmp/ddd.cmd:3: Error in sourced command file:
Bogus trace status reply from target: timeout
(gdb)

and the software running on the console does not get halted.

The bridge seems to indicate a successful connection.
~/umdk/umdkv2-bin$ ./gdb-bridge -l 8000
UMDKv2 Bridge Tool Copyright (C) 2014 Chris McClelland

Waiting for GDB connection on :8000...
Got GDB connection from 127.0.0.1:60070

Using the m68k-elf-gdb and gdb-bridge binaries supplied in the wiki, on Ubuntu 16.04.
And a wireshark packet capture:
https://vps.tasossah.com/.autoindex/umdk/umdk_gdb-bridge.pcapng

[Chris McClelland]

That sounds like DDD is trying to do some unsupported things on startup. It's possible the Ubuntu build of DDD has a different default config than the one supplied with Debian. It would be good to identify the offending startup option so we can fix it.

Try stopping all the bridge and ddd processes, doing "rm -rf ~/.ddd" and then trying again. It's worth looking to see if you have a ~/.gdbinit too, and removing it if necessary. Also, the ddd.sh script enables logging to /var/tmp/gdb.log, which will prove useful (post it here, I'll have a look):

https://github.com/makestuff/umdkv2/blob/20170319/scripts/ddd.sh#L4

There's also a ddd log generated in ~/.ddd/log, which may have helpful information too.

Chris

--
You received this message because you are subscribed to the Google Groups "UMDKv2 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tasos Sahanidis]

Before attempting to use DDD, I used the m68k-elf-gdb binary directly with just target remote localhost:8000 and got the same issue, so it is not something exclusive to ddd.
I just checked, and no ~/.gdbinit exists.

Relevant logs:
https://vps.tasossah.com/.autoindex/umdk/gdb.log
https://vps.tasossah.com/.autoindex/umdk/ddd.log

To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+...@googlegroups.com.

[Chris McClelland]

So that gdb.log implies that the gdb-bridge -l 8000 process is just not responding to anything gdb throws at it. I would expect the gdb.log to look like this:

w \x03+$qSupported:multiprocess+;qRelocInsn+#2a
r +$#00
w +$Hg0#df
r +$#00
w +$qTStatus#49
r +$#00
w +$?#3f
r +$S05#B8
w +$Hc-1#09
r +$#00
w +$qC#b4
r +$#00
w +$qAttached#8f
r +$#00
w +$qOffsets#4b
r +$#00

Presumably ordinarily the gdb-bridge process just prints "Got GDB connection from 127.0.0.1:60070" and nothing else? And it doesn't quit, meaning you have to ctrl-C it?

Can you try running the gdb-bridge under strace:

(strace -f -s1024 ~/umdkv2-bin/gdb-bridge -l 8000 2>&1) > gdb-bridge.log

...and send me the resulting gdb-bridge.log, after you've tried again?

Chris

To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+unsubscribe@googlegroups.com.

[Chris McClelland]

BTW, you may have to install it:

sudo apt-get install strace

[Tasos Sahanidis]

No worries, I'm familiar with strace.

Yes, all it does is print the "got gdb connection" message and then nothing else. If I turn off the megadrive I get usb errors, which makes sense.

I think [pid  5665] ioctl(9, USBDEVFS_REAPURBNDELAY, 0x7fff7b29da90) = -1 EAGAIN (Resource temporarily unavailable) might be related.
https://vps.tasossah.com/.autoindex/umdk/gdb-bridge.log.gz

[Chris McClelland]

I can see from your strace that the commands from gdb are received correctly. The first byte (see line 2267) is a 0x03, which is handled here:

https://github.com/makestuff/umdkv2/blob/20170319/gdb-bridge/remote.c#L367-L371

So it looks like the subsequent call to umdkDirectReadLong() is hanging. That is one of the most basic operations, on which everything relies, so it should not hang like this. Did you go through the testing procedure outlined in the wiki[1]?

Chris

[1]https://github.com/makestuff/umdkv2/wiki/Getting-Started

To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+unsubscribe@googlegroups.com.

[Tasos Sahanidis]

Yes, I ran all of those tests when I first received the board, and there were no errors.

I ran the bridge again, and got this:
Got GDB connection from 127.0.0.1:57040
umdkDirectReadBytes(): Illegal direct-read from 0xFF0102-0xFF0103 range!
umdkDirectWriteBytes(): Illegal direct-write to 0xFF0102-0xFF0103 range!

That error doesn't seem to be consistent though, as in, it doesn't always show up.

[Chris McClelland]

That suggests that the ROM you're trying to interrupt has its VBlank routine in WRAM, which will cause problems. You can check it like this:

od -tx4 -Ax -w4 -v --endian=big     your-rom-file.bin     | head -50 | grep 000078

If that returns something like "000078 00ff0102" then you're hitting a known issue[1] which affects a small number of game ROMs. The workaround is to wire up the brkAddr which can be passed in on the command-line, such that the initial hardware breakpoint should be installed at the given address rather than the VBlank address. The brkAddr value is read correctly from the command-line[2], but is never used. Its value could be written to a global variable ("g_brkAddr", perhaps) and then checked for as an override in the interrupt code[3]. You could give it a try and send me a pull-request if you wish[4]. Otherwise, you should try with a different ROM.

Chris

[1]https://github.com/makestuff/umdkv2/issues/3

[2]https://github.com/makestuff/umdkv2/blob/20170319/gdb-bridge/main.c#L207-L215

[3]https://github.com/makestuff/umdkv2/blob/20170319/gdb-bridge/remote.c#L370-L372

[4]Just fork the umdkv2 repo, apply your changes to a feature-branch ("brk-addr", perhaps) and then do a pull-request against the dev branch of my repo.

To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+unsubscribe@googlegroups.com.

[Tasos Sahanidis]

~/Επιφάνεια εργασίας/memtest68k/memtest68k_ctr$ od -tx4 -Ax -w4 -v --endian=big memtest68k\ beta1.4.bin | head -50 | grep 000078
000078 00ff0136

Which, if I understand correctly, would explain why it didn't work.

I tried Sonic 2 (which admittedly I should've done earlier), and that seems to work fine, although ddd can be a bit unreliable at times.

I guess I'll look into it once I familiarise myself more with how this works.
Thanks!

[Chris McClelland]

That's right, a vblank of 0xFF0136 is not going to work.

The gdb interrupt (i.e what happens when you hit <Escape> in gdb) works by writing (via USB) the address of the monitor (0x400000) to the illegal instruction vector (0x000010), and then overwriting the first instruction of the vblank routine (whose 32-bit address is listed in the vblank vector 0x000078) with the illegal instruction opcode (0x4AFC). The next time the vblank triggers, the CPU fetches the illegal instruction opcode, which causes an illegal instruction exception, forcing the CPU to jump to the monitor.

This process only works if the vblank routine is somewhere which can be directly read or written over USB, which in practice means anywhere in the lower 8MiB of address-space: 0x000000-0x7FFFFF. Under normal conditions, gdb can only read from the upper 8MiB of address-space by delegating the task to the 68000 itself (hence the distinction in the code between "direct" and "indirect" reads/writes).

Chris

To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+unsubscribe@googlegroups.com.