Previous Thread
Next Thread
Print Thread
#101809 09/30/15 07:55 PM
Joined: Sep 2015
Posts: 1
D
Member
OP Offline
Member
D
Joined: Sep 2015
Posts: 1
Hi!
I'm writing some gdb stub for MAME, but I have some troubles with it.

1) I have running_machine. How can I get list of general registers for running machine?
2) Reading/writing memory.

Last edited by Dr. MefistO; 09/30/15 08:23 PM.
Joined: Aug 2011
Posts: 18
Likes: 1
D
Member
Offline
Member
D
Joined: Aug 2011
Posts: 18
Likes: 1
The best way to figure out how to do these things is look for code that already does them in MAME. MAME's debugger uses operating system independent views to operate on the data in the running system. The code for each of these views is in:

https://github.com/mamedev/mame/tree/master/src/emu/debug

And to more specifically answer each of your questions:

1. https://github.com/mamedev/mame/blob/master/src/emu/debug/dvstate.c

2. https://github.com/mamedev/mame/blob/master/src/emu/debug/dvmemory.c

/Andrew

Joined: Aug 2015
Posts: 405
Senior Member
Offline
Senior Member
Joined: Aug 2015
Posts: 405
I had a similar idea some time ago and ended up in that area of the code base.

Now I am curious if it is possible to use the luaengine to do things like a GDB server and/or high level debugger support for homebrew development?! I haven't looked at it yet though but heard that the luaengine is very capable and can access most internal structures.


Because I can
Joined: Aug 2011
Posts: 18
Likes: 1
D
Member
Offline
Member
D
Joined: Aug 2011
Posts: 18
Likes: 1
Yeah, from what I understand, this is one of the main intents of the Lua engine. It's still very much under development, but making Lua capable of doing everything the current debugger interface is capable of at a low level may very well be its goal (hopefully someone who spearheaded the Lua integration stuff can confirm or deny here).

In my somewhat limited opinion, the more we are capable of interfacing MAME's debugger with debuggers that have been developed for years (GDB, Ida Pro, etc), the more developers will feel comfortable working with MAME. I don't know how possible this is or to what extent we can do it though, so I may be off base here smile.

I've never spent the time to really understand the various ways the current, internal debugger pokes into the MAME execution loop, but I'm really interested in assisting with the work to make it more accessible. There was some talk about developing a general API layer, but I believe real life got in the way of a final draft of that spec.

Joined: Aug 2015
Posts: 405
Senior Member
Offline
Senior Member
Joined: Aug 2015
Posts: 405
The limitation of GDB is that it is not capable of detecting target architecture by probing, you need to set it up in compile time I believe.

There are alternatives which have more of a run time selection of archtecture but I think we are close to that ourselves and "just" need to add a highlevel window.

Now, I have worked with debugger development professionally for Microtec around 1990 so I know that this aint easy with the optimizations, code movements, multi threading etc, but for a basic high level view we should be capable. The rest we can just leave to the real debugger projects, like GDB (with its limitations)

I started to investigate the STAB format just to see what is needed to get a highlevel window in MAME debugger for 6809 and my Vectrex project, check it out here But I never concluded how to actually hook it in but in my mind at the moment and if I take it up again it should be hooked in through the luaengine.


Because I can

Link Copied to Clipboard
Who's Online Now
5 members (Hydreigon, r09, box, 2 invisible), 16 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,085
Posts119,081
Members5,014
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com