[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[cdt-debug-dev] GUI vs. commands to handle target specifics
|
There is a lot of enthusiasm for building the ultimate GUI that can
potentially support all possible hardware.
Personally, the idea fails to excite me and I find it disturbing that
so much CDT talent is diverted to discuss/create a GUI to handle
target startup instead of boring bug fixes to the generic GDB support.
I find that once CDT GDB support(like our plugin) supports startup
commands, the residual lacking support for target specifics is dwarfed
by more generic CDT GDB requirements(like having breakpoints work
properly).
The problem is that a development/product board could require just
about any conceivable weird procedure before the debugger is let loose
on it. GDB commands is kinda like a programming language with its
flexibility and power. A GUI just seems like the wrong tool as it is
limited to whatever the developer of the GUI managed to dream up
beforehand.
If a platform is well understood, fairly static in its properties and
popular, a GUI is great.
BTW, the Zylin Embedded CDT plugin handles target connection via a
script typically like the script below, which should cover the
sensible GDB servers(TCP/IP) and less sensible targets that have
embedded some board specific into GDB(e.g. target bdi)
target <whatever>
monitor XXX // program flash???
monitor YYY // reset??
--
Øyvind Harboe
http://www.zylin.com