[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cdt-dev] question on CDT breakpoint properties dialog
- From: Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
- Date: Tue, 11 Oct 2011 15:41:30 -0400
- Accept-language: en-US
- Acceptlanguage: en-US
- Delivered-to: email@example.com
- Thread-index: AcyIRoFKhfUM2nvPTAC3FuOzYFYNoQAAxLKQ
- Thread-topic: [cdt-dev] question on CDT breakpoint properties dialog
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
> Sent: Tuesday, October 11, 2011 2:49 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] question on CDT breakpoint properties dialog
> > One aspect that I think will be of interest in the near
> > future is to provide breakpoints that are target-specific.
> I agree. We've talked about this several times in the past
> and there's been a few really nice ideas that have floated
> around. The challenge would be to create something that
> would work across different debugger implementations.
> Unfortunately the breakpoint filtering implementation we have
> in our product is almost as bad as CDTs so I don't think it
> would make sense to contribute it. But we'd be happy to
> support the effort if someone else has time to look at it.
I believe that the problem up to now has been not having
enough momentum to convince contributing companies to invest
the necessary time.
TI has a solution that makes use of the new Flex Hierarchy
breakpoints view and I believe they would like to see it
in CDT (or even platform).
Tensilica also has some work done on that front.
And I believe Freescale as well.
Maybe by showing clear commitment to make this happen, we
can convince others (read: their managers :-)) to allocate
some time to this.
> > Another important feature is to be able to set
> > breakpoint attributes _before_ actually planting the breakpoint.
> Yes, I've mentioned this in one of the bugs I created:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=360280. We do
> have this feature in our product and we'd look to contribute it here.
I didn't see it explicitly mentioned (I guess point 2 of the bug kind
of points to it), but I'm glad that is part of the planned contribution.