* Bare metal "server" - cleaning up after a program
@ 2015-10-08 22:27 Juha Aaltonen
2015-10-08 22:40 ` Juha Aaltonen
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Juha Aaltonen @ 2015-10-08 22:27 UTC (permalink / raw)
To: gdb-mailing list
I've been writing some kind of bare metal standalone gdb server/stub
that works through a serial line.
The problem is: when to clean up between debugged programs?
I have been wondering about the beginning of loading in a new program
("X0,0"-packet).
Maybe there is a better way/situation.
Gdb seems so focused to debugging processes running within an OS, that
"interpretation" in context of bare metal environment is hard.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bare metal "server" - cleaning up after a program
2015-10-08 22:27 Bare metal "server" - cleaning up after a program Juha Aaltonen
@ 2015-10-08 22:40 ` Juha Aaltonen
2015-10-08 22:59 ` Duane Ellis
2015-10-09 9:26 ` Pedro Alves
2 siblings, 0 replies; 4+ messages in thread
From: Juha Aaltonen @ 2015-10-08 22:40 UTC (permalink / raw)
To: gdb-mailing list
Or would 'kill' ('k'-packet) be "the choice"?
On Fri, Oct 9, 2015 at 1:27 AM, Juha Aaltonen <turbopultti@gmail.com> wrote:
> I've been writing some kind of bare metal standalone gdb server/stub
> that works through a serial line.
>
> The problem is: when to clean up between debugged programs?
> I have been wondering about the beginning of loading in a new program
> ("X0,0"-packet).
> Maybe there is a better way/situation.
>
> Gdb seems so focused to debugging processes running within an OS, that
> "interpretation" in context of bare metal environment is hard.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bare metal "server" - cleaning up after a program
2015-10-08 22:27 Bare metal "server" - cleaning up after a program Juha Aaltonen
2015-10-08 22:40 ` Juha Aaltonen
@ 2015-10-08 22:59 ` Duane Ellis
2015-10-09 9:26 ` Pedro Alves
2 siblings, 0 replies; 4+ messages in thread
From: Duane Ellis @ 2015-10-08 22:59 UTC (permalink / raw)
To: Juha Aaltonen; +Cc: gdb-mailing list
>> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bare metal "server" - cleaning up after a program
2015-10-08 22:27 Bare metal "server" - cleaning up after a program Juha Aaltonen
2015-10-08 22:40 ` Juha Aaltonen
2015-10-08 22:59 ` Duane Ellis
@ 2015-10-09 9:26 ` Pedro Alves
2 siblings, 0 replies; 4+ messages in thread
From: Pedro Alves @ 2015-10-09 9:26 UTC (permalink / raw)
To: Juha Aaltonen, gdb-mailing list
On 10/08/2015 11:27 PM, Juha Aaltonen wrote:
> I've been writing some kind of bare metal standalone gdb server/stub
> that works through a serial line.
>
> The problem is: when to clean up between debugged programs?
> I have been wondering about the beginning of loading in a new program
> ("X0,0"-packet).
> Maybe there is a better way/situation.
>
> Gdb seems so focused to debugging processes running within an OS, that
> "interpretation" in context of bare metal environment is hard.
I find it hard to answer the question, because I don't really understand
what you mean by "clean up". Maybe you want to
use "target extended-remote" instead, and be able to use "kill" and "run"?
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-10-09 9:26 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-08 22:27 Bare metal "server" - cleaning up after a program Juha Aaltonen
2015-10-08 22:40 ` Juha Aaltonen
2015-10-08 22:59 ` Duane Ellis
2015-10-09 9:26 ` Pedro Alves
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).