[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-debug-dev] Projectless debugging broken in CDT CVS HEAD 4.0
|
- Why does a debug session need a binary parser at all? "all" CDT should do is to point GDB at the file that the user specifies at his own peril. CDT should present any error message from GDB, but other than that not occupy itself with what constitutes a valid executable for debugging purposes. I think I would like to see a stronger separation between CDT build/edit & CDT debugging/less dependencies.
It would be great if the build/edit/indexing stuff could be freer to mess around with the parsers without worrying about the debugger??
Today a debug session requires an executable/symbol file, but really that should be optional as one or more symbol files can be loaded from the GDB command console(e.g. in a startup script).
The usage of the binary parser is not limited by the executable validation on the session startup. It is also used to get the symbols before and durring the session. In gdb 6.5 the mi symbol query commands are not implemented and even if it was, it would be available during the gdb session only.
- Remove requirement for a dummy project to be able to do projectless debugging
Removing the project requirement is not easy, a lot of code needs to be changed.
-----Original Message-----
From: cdt-debug-dev-bounces@xxxxxxxxxxx [mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Øyvind Harboe
Sent: 19 March 2007 17:12
To: cdt-debug-dev@xxxxxxxxxxx
Subject: [cdt-debug-dev] Projectless debugging broken in CDT CVS HEAD 4.0
CDT CVS HEAD broke projectless debugging today.
Projectless debuging w/Zylin Embedded CDT works as follows:
- Create dummy empty C/C++ project.
- Create a debug session that uses the dummy C/C++ project
- Point the debug session to an .exe or .elf file anywhere inside or outside the project. Zylin Embedded CDT plugin removes the restriction that an executable must be located inside the project for which the debug session is tied to.
- Launch debug session.
---
After updating to CDT CVS HEAD, I got this exception(CExtensionUtil.java):
throw new CoreException(new Status(IStatus.ERROR, CCorePlugin.PLUGIN_ID, -1,
CCorePlugin.getResourceString("CDescriptor.exception.providerNotFound"),
null)); //$NON-NLS-1$
The problem was that ref.gedID() == "" on the line below...
IExtension extension = extensionPoint.getExtension(ref.getID());
---
Current workaround: create a fresh dummy project. Go to advanced settings and enable the right binary parser.
Some comments/wishlist:
- Why does a debug session need a binary parser at all? "all" CDT should do is to point GDB at the file that the user specifies at his own peril. CDT should present any error message from GDB, but other than that not occupy itself with what constitutes a valid executable for debugging purposes. I think I would like to see a stronger separation between CDT build/edit & CDT debugging/less dependencies.
It would be great if the build/edit/indexing stuff could be freer to mess around with the parsers without worrying about the debugger??
Today a debug session requires an executable/symbol file, but really that should be optional as one or more symbol files can be loaded from the GDB command console(e.g. in a startup script).
- Remove requirement for a dummy project to be able to do projectless debugging
--
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit _______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
--
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
