[cdt-debug-dev] Re: Applying patches

["Øyvind Harboe" <oyvind.harboe@xxxxxxxxx>]

On Fri, Mar 28, 2008 at 9:21 PM, Alain Magloire <alain@xxxxxxx> wrote:
> >
>  > >  Bonjour,
>  > >
>  > >   Folks,  a bunch of outstanding patches were in the backlog, I help
>  > clean a
>  > >  little, thanks to Elena:
>  > >
>  > >  bugs
>  > >  219863 nor P3 Wind ken.ryall@xxxxxxxxx ASSI regression: Address
>  > breakpoints
>  > >  inserted from console do not resolve location properly
>  > >  218260 nor P3 Wind cdt-debug-inbox@xxxxxxxxxxx NEW Performance issues
>  > while
>  > >  stepping through with many threads
>  > >  221944 nor P3 Wind cdt-debug-inbox@xxxxxxxxxxx NEW Cannot display long
>  > long
>  > >  int as hex
>  > >
>  > >  features
>  > >  220045 nor P3 Wind cdt-debug-inbox@xxxxxxxxxxx NEW Debuger is stopping
>  > on
>  > >  non-existing breakpoints for files with same name
>  > >  221408 nor P3 Wind cdt-debug-inbox@xxxxxxxxxxx NEW Ability to move
>  > >  breakpoints manually to a different line
>  >
>
>  Bonjour O:yvind,
>
>  > Merci!
>  >
>
>  It should go to Elena.

Unless someone *applies* those patches, they won't be effectively
shared. I'm glad to see
evidence of patches being applied.

Of course a big thanks to Elena for fixing the problems in the first place! :-)

>  > I'm just wondering: why is there so little activity on the CDT
>  > GDB implementation?
>  >
>
>  Mea culpa, I have been quite busy.

You're using the QNX address, but I thought you had moved on.

>  > There are a fair number of "trivial" fixes like the above that will
>  > make a *big* difference.
>  >
>  > E.g. this bug is serious enough that it should have seen activity if
>  > there was anyone at all working full time on CDT GDB:
>  >
>  > https://bugs.eclipse.org/bugs/show_bug.cgi?id=208984
>  >
>
>  In this case, is this the right approach?

Nope, and it says so in the report. It just points a finger at the problem
by showing that disabling a piece of code makes the problem go away.

> The reason we use the process
>  factory class it because it allow us some flexibility, like being able to
>  send different signal to the process.  It is not possible to do it with
>  Runtime.exec.

Of course I'd like to see the process factory fixed. First step is to determine
that is broken of course.

>  It is something that you see only in your environment or a general problem?

I don't know how general the problem is.

>  I can see ProcessFactory taking sometimes since it needs to load a dll, the
>  code is implemented via JNI, but 10 seconds, seem like an awfully long
>  time...

It's been so long so I've forgotten most about this. If nobody works
on it on the
other end, I kinda don't see the point in working on it. But if you are saying
that someone *will* act on further input, then I'll try to dig into
this next week.

-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit