BreakpointManager.java is broken

[Øyvind Harboe]

The attached patch disables broken code in BreakpointManager.java

I don't know what the fix is, but the file name can be
the binary e.g. foo.elf, so the syntax break foo.c:xxx can't be
blindly used.

I think it is best to disable this code until it can be implemented
correctly.


Objections?

[Elena Laskavaia]

If you remove this breakpoints on static functions would not work.
Btw how can you create function breakpoint from UI which does not have
proper file?

In any case you cannot attach path to this e-mail it has to be bug report.

Post by Øyvind Harboe
The attached patch disables broken code in BreakpointManager.java
I don't know what the fix is, but the file name can be
the binary e.g. foo.elf, so the syntax break foo.c:xxx can't be
blindly used.
I think it is best to disable this code until it can be implemented
correctly.
Objections?
--
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit

[Schaefer, Doug]

Yes, patches have two main requirements.

1) They need to be in bugzilla so that we can keep tabs on them for IP checking purposes at Eclipse.

2) They have to be good. There are many criteria for this. But you need to consider that there are many users of the CDT out there using it in many ways. Patches that don't consider this are unacceptable. And, unfortunately, we've had many patches that fit into that category.

Doug.

-----Original Message-----
From: cdt-debug-dev-bounces-j9T/***@public.gmane.org [mailto:cdt-debug-dev-bounces-j9T/***@public.gmane.org] On Behalf Of Elena Laskavaia
Sent: Wednesday, April 02, 2008 10:08 AM
To: CDT Debug developers list
Subject: Re: [cdt-debug-dev] BreakpointManager.java is broken

If you remove this breakpoints on static functions would not work.
Btw how can you create function breakpoint from UI which does not have proper file?

In any case you cannot attach path to this e-mail it has to be bug report.

Post by Øyvind Harboe
The attached patch disables broken code in BreakpointManager.java
I don't know what the fix is, but the file name can be the binary e.g.
foo.elf, so the syntax break foo.c:xxx can't be blindly used.
I think it is best to disable this code until it can be implemented
correctly.
Objections?
--
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit

[Øyvind Harboe]

Post by Elena Laskavaia
If you remove this breakpoints on static functions would not work.
Btw how can you create function breakpoint from UI which does not have
proper file?

I don't know that you can.

Try breaking at an address in the .elf that has no source code tied to
it, or at an address outside the .elf entirely(e.g. interrupt vector, operating
system, etc.).

For embedded debugging the GDB console is your friend. CDT treats
the GDB console as an abomination that should be hidden if at all
possible. I'm advocating the oposite that CDT should strive to make the
GDB console *more* available and better supported(e.g. by adding back
the GDB prompt).

Post by Elena Laskavaia
In any case you cannot attach path to this e-mail it has to be bug report.

I'm trying to use cdt-debug-dev to discuss problem and possible solutions
before posting a bug report.

Should I post a bug report rather than "cluttering" cdt-debug-dev?

Either is fine by me as long as it is an effective forum for discussion.

[Elena Laskavaia]

If you cannot create it from UI when this code would not be executed. I
don't get what you trying to fix.
If you type it in console it would work (on CDT HEAD)

Post by Øyvind Harboe

Post by Elena Laskavaia
If you remove this breakpoints on static functions would not work.
Btw how can you create function breakpoint from UI which does not have
proper file?

I don't know that you can.
Try breaking at an address in the .elf that has no source code tied to
it, or at an address outside the .elf entirely(e.g. interrupt vector,
operating
system, etc.).
For embedded debugging the GDB console is your friend. CDT treats
the GDB console as an abomination that should be hidden if at all
possible. I'm advocating the oposite that CDT should strive to make the
GDB console *more* available and better supported(e.g. by adding back
the GDB prompt).

Post by Elena Laskavaia
In any case you cannot attach path to this e-mail it has to be bug

report.
I'm trying to use cdt-debug-dev to discuss problem and possible solutions
before posting a bug report.
Should I post a bug report rather than "cluttering" cdt-debug-dev?
Either is fine by me as long as it is an effective forum for discussion.
--
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit
_______________________________________________
cdt-debug-dev mailing list
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

[Øyvind Harboe]

Post by Elena Laskavaia
If you cannot create it from UI when this code would not be executed. I
don't get what you trying to fix.
If you type it in console it would work (on CDT HEAD)

The problem is restoring breakpoints to labels that do not correspond to
a source file. This would typically be something like "break reset_vector"
which breaks at some machine code inside the .elf file, but outside source
files associated with that .elf file.