simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(


From: Klaus Rudolph
Subject: Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions)
Date: Tue, 19 Oct 2004 20:57:33 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.6) Gecko/20040114

Paul Schlie schrieb:

I'm using Mac OSX with the latest development versions of gnu tools, and
choose to try the "old" C version to avoid some Linux communication
socket/port dependencies which seem to be present in simulavrxx from
reviewing the mail-list, and wanted to try to keep things simpler by not
having to deal initially with potential C++ coding/debug issues.

Yes, that I could realy understand :-)

(personally, I think it would be a good idea to continue to support and
maintain simulavr, and possibly not think of it as "old" code, but rather as
the parent C implementation, as I don't see any good reason to abandon it in
favor of simulavrxx requiring C++ at the moment)
You are right if you want to have simulavr also in the future, especially while simulavrxx is currently not moved to the windows world. But I wrote simullavrxx because I need a lot
of new features and a much (for me) easier way to do this. Object oriented
C-coding is something I donĀ“t like very much. But that is a discussion of taste. From my side I will implement only new things in simulavrxx and simulavr is for me "old" code. Simulavrxx is not simply a c++ copy of simulavr, no, it is completly
new (but some lines are copied, like gdbserver things :-))).

- are there any fixes in simulavrxx which have not been back-ported yet to
simulavr which would be helpfu

I have no idea how many bugs are inside simulavr. The code on simulavrxx is nearly complete
new, so there is no "bugfix" which is not putted to simulavr.

- it also may be a good idea to contribute simulavr to the gdb/binutils cvs
development branch, to enable gcc/binutils/gdb/etc. bug reporting and
verification via target simulation to proceed more easily to the benefit of
those interested in gnu avr tools.

Not in my heands.... but I think simulation is not part of binutils for any plattform.

Thanks
 Klaus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]