wow. the GDB remote stub sure works in a way that I'm sure made sense to someone at some point
hmm. I've got three things: a program implementing a GDB stub, a python module to parse it, and a spec from the GDB documentation.
They do not agree, but I do not know enough about how this shit is SUPPOSED to work to tell which one is fucked.
I'm just gonna assume that someone compiled this code for the emulator and it has never worked. that'll let me keep more of my sanity.

can't find a breakpoint because the code that's encoding breakpoint values is encoding them into lowercase and the remote gdb stub is encoding them into uppercase.

so if the address of your address point has any hex digits, it'll fail.

because 80153ff8 != 80153FF8

COMPUTERS WERE A MISTAKE
and now I'm running into a completely different issue where the emulation stops, and the emulator looks like it's stopped on a breakpoint, but it apparently never tells the GDB remote about this. So it hangs forever
I could switch away from this janky untested hack version of the GDB protocol, except then I'd need a binary GDB compiled to match my target architecture, and I'm not sure one even exists.
I could try wiresharking my gdb stub but that seems like the actions of someone who on their last rope
@foone That someone sounds like you.
@foone that reminds me of some tribulations that @badlogic went through a while ago to get DJGPP DOS programs debugged with GDB 

@foone It's a network protocol, right?

Lowercasing proxy? 

@foone did you type that in ASCII or Unicode?
@noplasticshower I've got a special mastodon client that does ebcdic
@foone that's bad in so many ways.
@foone It appears you've reached your breaking point
@foone It sounds like we've been having similar days.
@foone this is the most cursed thing I’ve read in at least 48 hours.
Any possibility the prior user could have used an octal or full binary encoding? No case to switch.
@foone ain't any GDB stub supposed to make sense when it's ever finished?