This is the mail archive of the
ecos-maintainers@sources.redhat.com
mailing list for the eCos project.
RE: Debugger OS-awareness
- From: "Janez Ulcakar" <janezu at asystelectronic dot si>
- To: "Jonathan Larmour" <jifl at eCosCentric dot com>,"Andrew Lunn" <andrew dot lunn at ascom dot ch>
- Cc: <ecos-maintainers at sources dot redhat dot com>
- Date: Fri, 28 Feb 2003 17:11:10 +0100
- Subject: RE: Debugger OS-awareness
Hi,
You're correct in your assumptions. We've encountered that 'special function
spawned by the ICE' approach before, and I think it's better suited for an
ICE.
a) Does eCos already provide such a function (how's it called, where does it
take it's params from, and where do we read the results from and what
format)
or
b) should a debugger (we) provide a C source that the user includes in his
build
regards
janez
-----Original Message-----
From: Jonathan Larmour [mailto:jifl at eCosCentric dot com]
Sent: Friday, February 28, 2003 16:51
To: Andrew Lunn
Cc: janez dot ulcakar at isystem dot com; ulfh at ese dot se;
ecos-maintainers at sources dot redhat dot com
Subject: Re: Debugger OS-awareness
Andrew Lunn wrote:
>>>- getting the specs on how to reach kernel object info from freeze mode
>>
>>freeze mode? We don't have much in the way of targets supporting power
>>management at all (although the support exists) so I'm not clear what
>>you're getting at.
>
>
> This is running on an emulator. So i guess he means the emulator has
> stopped executing instructions. He then wants to know how to poke
> around the emulated memory to find out about tasks.
>
> He basically needs to implement in the emulator the functions Nick
> added a few weeks ago to find out about current threads etc.
True, but that can be problematic with a configurable operating system
where the thread structure layout can change!
There have been two approaches to this in the past. The first one, which
has been preferred in the two examples (ICE support) so far that needed
this support, was to save the target context in the ICE, set the PC to a
special function pointed to from a well defined location, start the target
going again and that function will gather the data required for the
debugger, and then stop the target again when the function returns.
The second approach, used by some simulators, is to have good enough
support in the simulator and/or the port to run a ROM monitor, then
communicate with it using the GDB remote protocol! This is probably
slightly easier but has more overhead.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine