Eclipse DSDP-TM 2005-10-14
Brainstorming Notes
- Coordinating
debuggers (ARM+DSP) [Events?]
- Run
Control
- Module
Loads / symbol file association
- Inter-debugger
events
- Setting
up a multi-core launch
- TM
framework vs. extensions
- ECF
- Multiple
Connections with same target [Querying TM config]
- Unique
target ID
- ICE+agent
-> what is target stop
- Each
connection might be from different vendors
- Dependencies
- Setting
and querying properties (static or dynamic) could be done by getting APIs
using adapters or key-value pairs
- Dropping
into device debugging (or OS debugging) [Actions, events?]
- Debuggers
could be separate
- Too OS
focused?
- Workflow
scenarios
- Launching
scenarios
- Scenarios
for board bring up
- Only
memory & registers
- Maybe
without run-control or without project
- Connect
only
- OS
debugging
- Project-less
debugging
- Board
description
- Tools
or services in TM framework vs. just providing an opaque data store
- Purely
informational (docs)
- Board
manufacturer to create descriptions
- XML
files
- Composing
configuration by reference existing components descriptions
- Converting
different formats (XSLT?)
- Define
common formats
- Avoid
copying device descriptions
- Directly
suck in a standard format
- AI:
bring out current formats to the group (registers, memory, cores)
- Shared
board labs
- Launch
actions – scripting?
- Boarder
between TM and launch
- What
does “connect” mean?
- Security,
encryption & authentication
- Ssh
- Access
control (deployed devices)
- DSM
(management of deployed devices)
- Update
policies
- Other
tools/services beyond debug and download
- Events
between TM-aware tools/services?
- An
Eclipse issue/service (not TM)?
- ECF
with a loopback connection?
- Listeners
- Concerned
about moving debugger stuff down
- Many
levels of synchronized run-control
- Some
ICE have HW support for triggering each other. This must be possible to describe in the TM
- This
cross triggering could also be done in software by connectors
- AI:
Add legend to the DSDP-TM Base Architecture slide
- Connection
groups
- Could
help describe synchronous run-control
- Same
target or different
- Relationships
between connections in the same group e.g. agent+HW connection on the
same target
- Associate
launch with connection. Associate
launch with project. Associate
project with build-spec.
- System
unique properties provided by different sub-system (e.g. project,
connection, launch, etc) could be used for filtering by taking
intersection of existing ones.
Example of system unique properties could be
- Platform
(VxWorks, Linux, QNX, etc)
- Project
type (Application, Process, SHLIB, Kernel, LKM, etc)
- Architecture
(PPC, ARM, etc)
- CPU
variant
- Endianess
- Compatibility
(fuzzy?)
- Internal
properties could be translated to system unique properties by the
sub-system or sub-system plug-ins
- Wizard
for creating launches
- Open
source GDB using gdb-server need to launch agent on target. This is true for other agents
also. In the general case a
preparation stage might be needed before the agent is available to be
connected to.
- Some
target connections might want to connect from the wizard w/o asking in
order to auto-detect services or settings known by the target e.g. path
mapping
- How do
we get the executable to the target?
- Multiple
download paths
- Availability
in connection specification or discovered on the fly by action availability
- Choosing
a path in the launch
- In
other cases user might specify “use any available path”
- How
quickly will CDT adopt Darin’s new architecture?
- Remote
GDB – how to handle I/O to/from the debugged program?
- Workflow
- Preconditions
- First
product launch
- OS
already booted & configured
- Agent
already running
- Remote
X86 target running Linux
- Application
debugging using gdb over TCP/IP
- Project
is open with application
- Some
information already needed at build time (build spec)
- Lot
of pre-configuration might be shipped already
- Target
setup was not of startup
- Questions
should be deferred
- New
> Target Connection > Linux Agent
- Wizard
- IP
address
- Connection
name (possibly computed from other properties but could be modified or
overridden by user)
- Finish
- Target
connects (if option selected)
- Status
information is shown
- Select
executable > run > debug (create launch)
- System
picks correct launch type
- User
confirms connection (localhost-native vs. remote)
- Bring
up launch dialog
- Enter
target path or keep default
- Additional
download’s (shared libraries, configuration files, …)
- Press
“Debug” button
CDT
- Who
extends whom?
- Optional
CDT plug-in that depends on TM
- Extend
or add launch configuration type
- CDT
could contribute Actions to TM
- Right
click on a connection
- Contributed
to certain connection types
- Option
A: Each vendor (debugger provider) doing their LC-type (by deriving from
base type)
- New
launch configuration type: Remote c/c++ application
- Option
B: Add an extension point to CDT (or platform?) such that tools/actions
can be added to a launch
- Problem:
not all debugger back-ends might support TM extension
- Option
C: Contribute connection to debugger dropdown
TM API
- Connection
in launch: reference or copy?
- Share
connections with same mechanisms as launches
- Warning
“changing global settings”
- getConnectionData(ref)
- showConnectionSelection(filter)
- TM to
define a Widget for connection selection
- Connect()
vs. isConnected()
- RunAction
– in first version to be done by delegate