This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bare metal "server" - cleaning up after a program


>> Gdb seems so focused to debugging processes running within an OS, that
>> "interpretation" in context of bare metal environment is hard.

Bingo - you hit the problem nail on the head, bullseye!

you also need to consider the situation when you want to âhot-attachâ to a running process.
perhaps your target is hungâ and you want to attach to see *why is this thing dead?â
or perhaps - where is this thing at?

You might want to consider this to solve certain other problems:

Use GDB-Python extensions
	Then - using Python, create your own new GDB commands.
	These commands - effectively send a GDB Remote packet to your gdb server

GDB Python is enabled by default on Linux (Linaro GDB releases)
And - latest release of (windows binary) Linaro GDB includes GDB Python [previously it was not enabled on windows]
The ARM Embedded GDB (windows binary) already had this feature enabled.
	
What i mean is this:  
	Using Python, you can create any new GDB command
	Using python, you can execute any arbitrary GDB command,
	specifically the special maintenance command that lets you send an arbitrary packet
	You can also get the RESULT of that arbitrary [packet] command.

	You then your python module must take apart the ascii text the reply.. 

What would be better is this

	If GDB-Python exposed a âremoteâ object that let you execute the REMOTE commands more generally
	Itâs sort of a pain to âprintf()â your command into an ascii command line.
	Stuff the ascii command line into GDB
	Capture the output ascii text
	Then covert this ascii text back into Binary data.
	 (GDB need to expose more in the python area)
	Perhaps in the future, things will be better

	meanwhile - you do it they way I describe

Why is this important?

	This lets you create any new command in GDB, that can do *anything* you need in your bare metal target.

For example, you want to read/write  CP14/CP15 register  values?
	Your python script could clean up the MMU configuration
	or - perhaps Dump MMU mapping tables.

In future you could extend this to create a command called:  âmmu-dumpâ  or    âmmu-explain ADDRESSâ 
These would use MCR/MRC instructions to read the MMU config registers, then access the MMU page tables
and perhaps dump the mmu configuration, and/or translate a virtual address to a physical address.

In your case - launching a new application

Once your GDB-Python script has done what it needs to do (i.e.: Reconfigure, reset the target) you can use the normal âloadâ commands to load your image.

-Duane.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]