This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
It's a complex problem and as such has middle ground and negotiation dependant on the scale of the work:
- Corinna recently changed an architecture interface and, since it was straight forward, did the 'busywork'.
- The frame code, on the other hand, was anything but straight forward, it instead started with a single architecture and then expanded as back end maintainers did their (much appreciated) stuff. In the end though, a long list of architectures were simply deleted (should I have instead done the 'busywork' of frameifying the ns32k?).
Perhaps you can expand on your point by explaining where you would strike up the balance for making an invasive change such as asynchronous native (proc, ptrace) support. GDB has many many non-async embedded targets, but only two natives. Should we predicate the work on the modification of all the embedded inferiors? Or should we accept that the work is so key to GDB's future as a native that we can tolerate a few short term problems?
I think that in general you expanded on my point better than I could. As you say, it's a complex problem. You are proposing a simple principle, and my concern is that once such a thing is adopted it will be used to enforce simplistic solutions to complex problems. As I said before, the principle itself seems unobjectionable in many contexts. My concern is that it will be applied in cases where it is too simple.
Or, to put it another way: why do we need an overly simple statement about what we agree is a complex issue?
On your specific issue, I think that async native support would require either a flag day or supporting two separate interfaces for some time. A flag day is only acceptable if all major architectures can be converted simultaneously. Off the cuff I would say that supporting two separate interfaces would have to last for at least a year. Yes, this is hard. Yes, it leads to more duplicated work. A clean and elegant program is a goal, but it is not the only goal.
- multi-arch started '98, not finished - frames started dec? '02, finished nov '04 - event-loop started '98, finished jun? '04 - regcache started dec? '02, not finished
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |