Re: GDB is the GNU project's native debugger

Re: GDB is the GNU project's native debugger

[Paul Schlie]

> Ian Lance Taylor wrote:
> For what it's worth, I believe that is to some degree a
> misunderstanding.  The goal of the FSF is a completely free system
> (this goal has been achieved).  This free system is intended to be
> superior both technically and philosophically, and thus encourage
> people to switch to it.
> 
> Running free tools on non-free systems is interesting only to the
> extent that it helps lead to a fully free system.  This happens
> because it encourages a broader range of people to put resources into
> improving the free tools, and thus improving the free system.

> However, running free tools on non-free systems is counterproductive
> to the extent that they make the non-free systems more usable, and
> thus delay the adoption of completely free systems.
> 
> Using the free tools as advertisements of the effectiveness of the GNU
> project is not actually a goal of the FSF, contrary to what you
> suggest.

As a not so minor nit, the notion of "FREE" needs to clarified:

- "FREE" from GNU's perspective has always predominantly referred to the
intellectual properly content being "FREE" of proprietary encumbrances.

- there's no such thing as "FREE" from a financial/resource point of view,
everything consumes resources, and gets paid for one way or another; GNU's
project has been financed/resourced by both individuals and corporations
simply because it's either perceived as either the right thing to do, or
(more often than not) simply perceived as being less expensive than
alternative solutions.

- arguably, adopting any bias which inhibits the applicability of GNU's
tools, actually encourages/requires the development of likely proprietary
alternatives in contradiction of GNU's goals, and indirectly reducing
opportunity to fund continued advancements, (which seems quite counter
productive overall).

Re: GDB is the GNU project's native debugger

[Paul Breed]

>- arguably, adopting any bias which inhibits the applicability of GNU's
>tools, actually encourages/requires the development of likely proprietary
>alternatives in contradiction of GNU's goals, and indirectly reducing
>opportunity to fund continued advancements, (which seems quite counter
>productive overall).

Bingo.... I currently use the gcc toolchain to support an embedded product 
suite.

3 years ago 50% of my customers were screaming for linux hosted versions 
of  our
development environment, libraries and tools, we did that...
Today out of several thousand developers using our solution only 2 are 
hosting on linux.
Out gcc, and gdb tools are the only contact many of these people have with 
the FSF concept

I need a good debugging solution, if it can't be GDB then it will be a 
proprietary solution,
I'd much rather it be GDB, but a FSF isolationist approach to GDB will be 
counter productive.

Paul
CTO NetBurner....

Re: GDB is the GNU project's native debugger

[Elena Zannoni]

Paul Breed writes:
 > 
 > I need a good debugging solution, if it can't be GDB then it will be a 
 > proprietary solution,
 > I'd much rather it be GDB, but a FSF isolationist approach to GDB will be 
 > counter productive.

Same argument applies in native space, I am afraid. 

Re: GDB is the GNU project's native debugger

[Ian Lance Taylor]

Andrew Cagney <cagney@gnu.org> writes:

> > 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.
> 
> I waited a year, and nothing happened.

Personally, I would say that after a year you can go ahead and break
the code which has not been updated.

This doesn't necessarily mean that you should delete it immediately
(although of course it can be retrieved from CVS).  Just break it.

I don't know whether gcc has a notion of "primary platforms," as gcc
does.  I suppose that it would not be acceptable to break a primary
platform.

> Is such a rate of change possible if we're required to constantly
> schedule flag days, or wait for a year?

First, I'll note that if you provide a backward compatibility
interface, then the fact that some ports have not been updated does
not prevent you from continuing to work.

Second, what is your alternative?  If your alternative is to cause gdb
to not work on many popular platforms, then I suspect that is a false
choice.  In the long run the effect will be to lose users and
developers.  That is only acceptable if you are willing and able to be
the sole developer of gdb.  If not, then you must accomodate other
people and their schedules.

(Being the only developer may not be absurd.  For a couple of years I
was essentially the only developer of the binutils--other people
contributed target specific ports, but I wrote or rewrote every
significant change to the internals.  But the binutils are much
simpler than gdb.)

Ian

Re: GDB is the GNU project's native debugger

[Andrew Cagney]

>>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?

My post has context.  I've recently encountered situtations where 
developers were insisting that I test my changes on ULTRIX; or that I 
seek approval when making trivial and pre-announced changes.

As such we all need a reality check.  Remind ourselves what the overall 
objective here is; and against what baseline we should each measure our 
requests.

> 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.

I waited a year, and nothing happened.

I think it is first important to recognize that the pressure placed on 
GDB is different to that encountered by other members of the toolchain - 
binutils and gcc.  GCC, for instance, has a simple pipeline 
architecture: FRONTEND <tree> MIDDLEEND ... <tree> BACKEND.  Individual 
FRONT, MIDDLE and BACK ends can largely be developed in isolation, and 
plugged in and out at will.   Only when the <tree> is changed, as 
occurred when moving from RTL to SSA, to things get scary and slow 
careful engineering processes (as again applied to SSA) are required.

Contrast that to GDB, where underlying the architecture is a relatively 
complex web of objects (there's an O-O model fighting to get out of the 
C code :-).   When developing such a model a key process has to be 
refactoring the code - modifying the object model (changing 
relationships and interfaces) so that the next change can be 
accommodated - and a key attribute of refactoring is that each has a 
short cycle: taking days, and not years to complete.

If we look over GDB's [short list of not so] recent core changes, we 
find that for the true inovations such as:

- 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

the innovator did (I pushed through 3/4 of the above) implement backward 
compatibility so that out-of-date systems were given an opportunity to 
update and consequently waited-a-year or more.  When we examine how each 
of these changes panned out, though - the extra year makes no 
difference.  Only when compatibility code starts to be removed (or I 
stand my ground and require an update as an predicate to another 
contributions) that we see activity to revive out of out-of-date systems 
(and then only for a limited set).

You make the assertion:

 > A clean and elegant program is a goal, but it is not the only goal.

We're not talking here about clean or elegant code.  Rather we're 
discussing GDB's backlog of refactorings (struct value, struct location, 
struct symbol, ...); each made of many smaller changes; each 
establishing another part of a robust OO model; each dependant on 
earlier work; each ensuring a more maintainable code base; and most 
importantly each a prereq to adding advanced features to gdb.

Such refactorings need to be performed in time periods that amount to 
weeks, and not the months or years we currently see.

Is such a rate of change possible if we're required to constantly 
schedule flag days, or wait for a year?

Andrew

Re: GDB is the GNU project's native debugger

[Kip Macy]

I personally do not feel as strongly motivated by the GPL as many who
have or have at least tried to contribute to GNU software. However, I
also do not sympathize with those who strongly object to the GPL because
of the limitations it sometimes places on business use. It is the right
of those who have done the bulk of the work on a piece of software to
license it as they see fit. Thus I feel that I am fairly neutral in
this discussion.

One possible approach to discussing the difficult tradeoffs involved is
to take a page from legal discourse. Rather than speaking in terms of
"principles", talk about acceptance "criteria". To make their
application clear, you could create the moral equivalent of case law.
Create a document where you describe past issues such as async native,
frame handling, or architecture interface change, what the perceived
trade-offs were and why you made the decision that you did. This
document would be much more useful than wading through mail archives,
and it would make it easier, assuming you are self-consistent, to
justify future decisions.


			-Kip






On Thu, 18 Nov 2004, Ian Lance Taylor wrote:

> Andrew Cagney <cagney@gnu.org> writes:
> >
> > 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.
>
> > What I do see is continuing pressure and lobying, some times comming
> > from the most ironic of quarters :-)
>
> Well, you can make the lobbying public, or, since of course that may
> not be possible, you can ask for our input in an indirect fashion.
> I'm replying to the indirect query.  Naturally I don't have all the
> information which you have.
>
> > Anyway, would it be useful if the process, as you describe it, was
> > explicitly documented?
>
> I'm not sure it makes much difference, myself.  But on that question I
> may be too far on the inside, even though not a serious gdb developer.
> Perhaps for others with less historical knowledge, more documentation
> would be helpful.
>
> Ian
>

Re: GDB is the GNU project's native debugger

[Ian Lance Taylor]

Andrew Cagney <cagney@gnu.org> writes:

> > The "clarification" in the last clause is not clear at all, and will
> > vary a great deal in the eye of the beholder.  One person's
> > architectural change allowing better support is another person's
> > arbitrary change requiring pointless busywork.  Who is responsible for
> > that busywork--the person making the change, or every single backend
> > maintainer?  These questions are not resolved by a general statement
> > in favor of supporting GNU systems.
> 
> 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.

> What I do see is continuing pressure and lobying, some times comming
> from the most ironic of quarters :-)

Well, you can make the lobbying public, or, since of course that may
not be possible, you can ask for our input in an indirect fashion.
I'm replying to the indirect query.  Naturally I don't have all the
information which you have.

> Anyway, would it be useful if the process, as you describe it, was
> explicitly documented?

I'm not sure it makes much difference, myself.  But on that question I
may be too far on the inside, even though not a serious gdb developer.
Perhaps for others with less historical knowledge, more documentation
would be helpful.

Ian

Re: GDB is the GNU project's native debugger

[Andrew Cagney]

Ian Lance Taylor wrote:

> The "clarification" in the last clause is not clear at all, and will
> vary a great deal in the eye of the beholder.  One person's
> architectural change allowing better support is another person's
> arbitrary change requiring pointless busywork.  Who is responsible for
> that busywork--the person making the change, or every single backend
> maintainer?  These questions are not resolved by a general statement
> in favor of supporting GNU systems.

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?

> When you talk about "attempt influence" I can't help but feel that you
> are exporting internal Red Hat dissension to the external world.  I've
> done plenty of embedded contract work, and frankly for most people
> getting the backend support into gdb is not all that important.  You
> just get one version of gdb working and stick with that for as long as
> you can--normally a few years.  (This has been somewhat broken
> recently as some new versions of gcc require new versions of gdb, but
> that was not historically the case--and indeed many people in the
> embedded world still use -gstabs+ when they compile to sidestep these
> problems).  I understand that within Red Hat things are different--Red
> Hat understandably tries to use a single source tree for both native
> and embedded work.

Red Hat, with it's GNU/Linux distributions (RHEL) uses a separate GDB 
rpm and not a combined source tree.  I also suspect that the contract 
engineering group you refer to ("Cygnus") are now rarely doing a GDB 
import, and are tending towards the model you describe.  If there were 
problems, I'm sure they would have been addressed.

What I do see is continuing pressure and lobying, some times comming 
from the most ironic of quarters :-)

Fortunatly, I also see a great deal of professionalism.  Embedded 
companies taking on the standards, meeting, and exceeding them.

Anyway, would it be useful if the process, as you describe it, was 
explicitly documented?

> My point is that in my experience, outside Cygnus/Red Hat, very few
> people's bottom line is affected by deprecating code or changing gdb
> internals.  So I think your point is wrong.

Andrew

Re: GDB is the GNU project's native debugger

[Ian Lance Taylor]

Andrew Cagney <cagney@gnu.org> writes:

> To address this (since you mention code removal) I've (lets face it is
> me willing to put my neck on the line and drive this forward) set
> clear technical criteria such as:
> 
> > * END-OF-LIFE frame compatibility module
> > GDB's internal frame infrastructure has been completely rewritten.
> > The new infrastructure making it possible to support key new features
> > ....
> 
> or:
> 
> - it has't built for a full release cycle
> - it has't worked for a full release cycle
> 
> to identify code that can be removed.

I don't have a problem with removing specific target backends that are
not supported.  I don't agree with the length of time--I think it
should be something like "a full release cycle or one year, whichever
is longer."  But I agree that in principle removing a specific
non-functional backend is not problematic.

> While this is helping, the fact that it is only by taking such action
> the code gets maintained tells us we should go further setting a
> clearer bar: for instance requiring test results against each major
> release; or clarifying that architectural changes to GDB's core
> allowing better support for native GNU systems take priority over
> concerns that it might break embedded code.

The "clarification" in the last clause is not clear at all, and will
vary a great deal in the eye of the beholder.  One person's
architectural change allowing better support is another person's
arbitrary change requiring pointless busywork.  Who is responsible for
that busywork--the person making the change, or every single backend
maintainer?  These questions are not resolved by a general statement
in favor of supporting GNU systems.

> > If you want to state that, where there is a direct and immediatete
> > conflict between the needs of GNU systems and the needs of other
> > systems, the needs of the GNU systems take priority, I could support
> > that.
> 
> In addition, many people (including I) are now in a situtation where
> their financial future is in part dependant on their ability to work
> on GNU software.  As such they are finding that this conflict directly
> affects their, or their peers, bottom line.  A manouver that
> influences the timing of a decision to deprecate (new code can't use)
> or end-of-life (removing) a mechanism or accept/reject a change has
> the potential to either cost or save these embedded / contract
> engineering companies and their employees 10's if not 100's of
> thousands of dollars.
> 
> (Having worked in both GNU native and enbedded contract engineering, I
> can confidently state that the embedded side is brutally cut throat
> and far more likely to attempt influence.  This is also why when
> accepting a new architecture or system I've tried to set clear
> consistent acceptance criteria).

When you talk about "attempt influence" I can't help but feel that you
are exporting internal Red Hat dissension to the external world.  I've
done plenty of embedded contract work, and frankly for most people
getting the backend support into gdb is not all that important.  You
just get one version of gdb working and stick with that for as long as
you can--normally a few years.  (This has been somewhat broken
recently as some new versions of gcc require new versions of gdb, but
that was not historically the case--and indeed many people in the
embedded world still use -gstabs+ when they compile to sidestep these
problems).  I understand that within Red Hat things are different--Red
Hat understandably tries to use a single source tree for both native
and embedded work.

My point is that in my experience, outside Cygnus/Red Hat, very few
people's bottom line is affected by deprecating code or changing gdb
internals.  So I think your point is wrong.

That's not to say that I am opposed to clear consistent acceptance
criteria for new backends.  Of course that is a good idea, and gcc
(which I think is clearly successful and should generally be the model
for this sort of development, as I've said before) has that as well.

> > If you want to state that this applies to considerations of resources,
> > and of which parts of gdb to mark obsolescent, I could not support
> > that.
> 
> I'm not sure what you mean.

I mean what I said in my second paragraph above, the one about the
"clarification."  In particular, it's very easy to apply a broad,
generally accepted statement in ways which are not, in fact, generally
accepted.

Ian

Re: GDB is the GNU project's native debugger

[Andrew Cagney]

> Andrew Cagney <cagney@gnu.org> writes:
> 
> 
>>GDB is the GNU project's native debuger.  While we're certainly happy
>>to accomodate people using GDB as either an embedded debugger or
>>native debugger on other systems, the need to persue GDB as a native
>>debugger on GNU systems must be our first priority.
>>
>>Do we all agree with this?
> 
> 
> While I think we all agree with this in some sense, I think you should
> spell out where you are going with this.
> 
> For example, it would be easy to use this statement as the motivation
> for removing features required for using gdb for embedded systems, or
> on Windows.  I don't think that would be appropriate.

I think this first needs a little context.

One group, the embedded companies have found that with very little 
effort (I believe the guesstimate is ~6 weeks) they can add an 
architecture to GDB, leveraging themselves a very powerful debugger. 
This work is typically contracted, and once the money dries up all 
incentive to further develop that code disappears.

This creates a very on-sided relationship.  The embedded targets get all 
the cool features of GDB while the native developers get to "support" 
(i.e., maintain) it.

To address this (since you mention code removal) I've (lets face it is 
me willing to put my neck on the line and drive this forward) set clear 
technical criteria such as:

> * END-OF-LIFE frame compatibility module
> 
> GDB's internal frame infrastructure has been completely rewritten.
> The new infrastructure making it possible to support key new features
> ....

or:

- it has't built for a full release cycle
- it has't worked for a full release cycle

to identify code that can be removed.

While this is helping, the fact that it is only by taking such action 
the code gets maintained tells us we should go further setting a clearer 
bar: for instance requiring test results against each major release; or 
clarifying that architectural changes to GDB's core allowing better 
support for native GNU systems take priority over concerns that it might 
break embedded code.

> If you want to state that, where there is a direct and immediatete
> conflict between the needs of GNU systems and the needs of other
> systems, the needs of the GNU systems take priority, I could support
> that.

In addition, many people (including I) are now in a situtation where 
their financial future is in part dependant on their ability to work on 
GNU software.  As such they are finding that this conflict directly 
affects their, or their peers, bottom line.  A manouver that influences 
the timing of a decision to deprecate (new code can't use) or 
end-of-life (removing) a mechanism or accept/reject a change has the 
potential to either cost or save these embedded / contract engineering 
companies and their employees 10's if not 100's of thousands of dollars.

(Having worked in both GNU native and enbedded contract engineering, I 
can confidently state that the embedded side is brutally cut throat and 
far more likely to attempt influence.  This is also why when accepting a 
new architecture or system I've tried to set clear consistent acceptance 
criteria).

> If you want to state that this applies to considerations of resources,
> and of which parts of gdb to mark obsolescent, I could not support
> that.

I'm not sure what you mean.

Andrew

Re: GDB is the GNU project's native debugger

[Steven Johnson]

Andrew Cagney wrote:

> GDB is the GNU project's native debuger.  While we're certainly happy 
> to accomodate people using GDB as either an embedded debugger or 
> native debugger on other systems, the need to persue GDB as a native 
> debugger on GNU systems must be our first priority.
>
> Do we all agree with this?
>
>
My 2c.

The statement doesnt mean anything.

As the code in GDB is developed by the donations of people, in either 
time or money to companies who spend time.  The "primary" focus of GDB 
will always be the focus of the majority of "donators/contributors" at 
any one time, and will change over time, as the groups "majority" need 
changes.

The (flavour of Open Source) licence is largely irrelevent, except to 
the point that it allows people to feel (more or less) comfortable in 
donating their time to a "common good".

So no, i dont agree with this statement.

I would agree with a statement that said "the majority of people (at the 
current time) who use GDB are debugging programs compiled with GCC".

After that, if tomorrow we get 1000 developers donating their time to 
support Windows XP native debugging of Visual C++, thats going to be the 
"priority" because they will swamp (by their needs and the level of 
their donation at the current time) the needs  and level of donation of 
all others combined.  And we as a group should be thankful for that, 
because it is unlikely that all that work will only be useful for one 
target platform, so even if it doesnt advance the philosophical war, it 
certainly advances the tool which we all use.

Andrew, Can you illuminate us as to why this "philosophical" debat has 
been raised?  What problem are you trying to solve or prevent?

My belief is one of the pleasures of the GDB community is the lack of 
this sort of largely pointless debate.

Steven

Re: GDB is the GNU project's native debugger

[Eli Zaretskii]

> From: Ian Lance Taylor <ian@wasabisystems.com>
> Cc: gdb@sources.redhat.com
> Date: 16 Nov 2004 12:35:28 -0500
> 
> For example, it would be easy to use this statement as the motivation
> for removing features required for using gdb for embedded systems, or
> on Windows.  I don't think that would be appropriate.
> 
> If you want to state that, where there is a direct and immediate
> conflict between the needs of GNU systems and the needs of other
> systems, the needs of the GNU systems take priority, I could support
> that.
> 
> If you want to state that this applies to considerations of resources,
> and of which parts of gdb to mark obsolescent, I could not support
> that.

I agree with Ian 100%, on all 3 accounts.

Re: GDB is the GNU project's native debugger

[Mark Kettenis]

   Date: Tue, 16 Nov 2004 12:28:24 -0500
   From: Kris Warkentin <kewarken@qnx.com>

   How do you define GNU system?  If you're looking at the OS, Linux is the 
   only GNU system in wide use since HURD is not mainstream.  If you define 
   it as a system using a GNU toolchain then I don't see that you're 
   particularily narrowing your scope since you now include many of the 
   embedded systems, BSDs, some Win32 such as Cygwin and MinGW.

The FSF is crystal clear on this.  While some of these systems are
more "free"[1] than others they should all be considered equal; no
effort should be spent on supporting these systems.

I disagree with this statement.

I also find it somwhat ironical that the Linux-kernel developers seem
to care less and less about freedom.  IMHO, these days, OpenBSD
approaches FSF "freedom" better than Linux.

Mark

[1] In the GNU sense.

Re: GDB is the GNU project's native debugger

[Mark Kettenis]

   Date: Tue, 16 Nov 2004 11:43:27 -0500
   From: Andrew Cagney <cagney@gnu.org>

   GDB is the GNU project's native debuger.  While we're certainly happy to 
   accomodate people using GDB as either an embedded debugger or native 
   debugger on other systems, the need to persue GDB as a native debugger 
   on GNU systems must be our first priority.

   Do we all agree with this?

While I'm sympathetic towards this goal, I must state that for me
personally supporting GDB on OpenBSD, FreeBSD and NetBSD has a higher
priority.

Mark

Re: GDB is the GNU project's native debugger

[Paul Schlie]

> Andrew Cagney wrote:
> GDB is the GNU project's native debuger. While we're certainly happy to
> accomodate people using GDB as either an embedded debugger or native debugger
> on other systems, the need to persue GDB as a native debugger on GNU systems
> must be our first priority.
>
> Do we all agree with this?

If the GNU project inclusive of GCC's supported hosts "and targets", yes.

(As after all, although possibly not as glamorous, GNU's tool suite,
 inclusive of GDB, been relied upon, and has historically been the basis of
 a non-insignificant component of the funding which had enabled the project
 to progress through the years; and shouldn't likely be disregarded, as most
 of the the world's code development and processor use is targeted for
 embedded systems, not PC's, and certainly not servers.)

Re: GDB is the GNU project's native debugger

[Ian Lance Taylor]

"Dave Korn" <dk@artimi.com> writes:

>   Hmm, so do you feel that my first para. would have been more near the truth if
> it had said that the encouraging/evangelising of OSS in general was only a
> *minor* goal of the gnu project, and that providing free tools on non-free
> systems was a tactical method rather than strategic goal?

I guess I would say that evangelising is a major goal, at least in
terms of discussing the benefits of free systems.  I agree that free
tools on non-free systems is a tactical method.

Ian

RE: GDB is the GNU project's native debugger

[Dave Korn]

> -----Original Message-----
> From: Ian Lance Taylor 
> Sent: 16 November 2004 18:11

> "Dave Korn" writes:
> 
> >   To my understanding, and correct me if you feel I've 
> misunderstood, a major
> > part of the purpose of the GNU project is to encourage and 
> evangelise the spread
> > of open source, and the strategic method for achieving that 
> goal is to provide
> > free software, in particular a free toolchain, across as 
> wide a range of
> > platforms as possible, 

> For what it's worth, I believe that is to some degree a
> misunderstanding.  The goal of the FSF is a completely free system
> (this goal has been achieved).  This free system is intended to be
> superior both technically and philosophically, and thus encourage
> people to switch to it.
> 
> Running free tools on non-free systems is interesting only to the
> extent that it helps lead to a fully free system.  This happens
> because it encourages a broader range of people to put resources into
> improving the free tools, and thus improving the free system.

> However, running free tools on non-free systems is counterproductive
> to the extent that they make the non-free systems more usable, and
> thus delay the adoption of completely free systems.
> 
> Using the free tools as advertisements of the effectiveness of the GNU
> project is not actually a goal of the FSF, contrary to what you
> suggest.


  Hmm, so do you feel that my first para. would have been more near the truth if
it had said that the encouraging/evangelising of OSS in general was only a
*minor* goal of the gnu project, and that providing free tools on non-free
systems was a tactical method rather than strategic goal?


> All of the above is of course my beliefs based on what I saw as it
> happened, and do not represent any sort of official position by
> anybody.

  You can very certainly <AOL> me on that one!


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: GDB is the GNU project's native debugger

[Ian Lance Taylor]

"Dave Korn" <dk@artimi.com> writes:

>   To my understanding, and correct me if you feel I've misunderstood, a major
> part of the purpose of the GNU project is to encourage and evangelise the spread
> of open source, and the strategic method for achieving that goal is to provide
> free software, in particular a free toolchain, across as wide a range of
> platforms as possible, and in particular the reason for the existence of the
> LGPL exception is to enable the GNU toolchain and software family to be ported
> to proprietary systems and to make inroads for open software there and convince
> users of proprietary systems of the value and benefits that can be obtained from
> the open source philosophy.

For what it's worth, I believe that is to some degree a
misunderstanding.  The goal of the FSF is a completely free system
(this goal has been achieved).  This free system is intended to be
superior both technically and philosophically, and thus encourage
people to switch to it.

Running free tools on non-free systems is interesting only to the
extent that it helps lead to a fully free system.  This happens
because it encourages a broader range of people to put resources into
improving the free tools, and thus improving the free system.

However, running free tools on non-free systems is counterproductive
to the extent that they make the non-free systems more usable, and
thus delay the adoption of completely free systems.

Using the free tools as advertisements of the effectiveness of the GNU
project is not actually a goal of the FSF, contrary to what you
suggest.

The fact that the GNU tools have become highly portable across a broad
range of systems is largely the result of the resources that have been
into them for business reasons, starting in the early days of Cygnus
and continuing in various successor companies.  Especially in the
early days, this work was sometimes done over the objections of the
FSF.

The LGPL in particular was an effort driven initially largely by
Cygnus (although Cygnus later found it to be unhelpful), and the LGPL
has since been largely disavowed by the FSF:
    http://www.gnu.org/licenses/why-not-lgpl.html

All of the above is of course my beliefs based on what I saw as it
happened, and do not represent any sort of official position by
anybody.

Ian

RE: GDB is the GNU project's native debugger

[Dave Korn]

> -----Original Message-----
> From: gdb-owner On Behalf Of Andrew Cagney
> Sent: 16 November 2004 16:43

> GDB is the GNU project's native debuger.  While we're 
> certainly happy to 
> accomodate people using GDB as either an embedded debugger or native 
> debugger on other systems, the need to persue GDB as a native 
> debugger 
> on GNU systems must be our first priority.
> 
> Do we all agree with this?


  Well, "Up to a point, Lord Copper".

  I will take it that you do not mean that the primary purpose of GDB is to run
under the HURD, since that doesn't really fully exist or work.  I'm not sure
what you mean by "GNU system**S**" in the plural, because that's the only one.
Unixen are largely proprietary, and GNU/Linux is GNU/Linux, and not just plain
GNU.  If you'd care to enlarge and clarify on the precise shade of meaning you
were attaching to the phrase, I might modify some of what follows from here.

  To my understanding, and correct me if you feel I've misunderstood, a major
part of the purpose of the GNU project is to encourage and evangelise the spread
of open source, and the strategic method for achieving that goal is to provide
free software, in particular a free toolchain, across as wide a range of
platforms as possible, and in particular the reason for the existence of the
LGPL exception is to enable the GNU toolchain and software family to be ported
to proprietary systems and to make inroads for open software there and convince
users of proprietary systems of the value and benefits that can be obtained from
the open source philosophy.

  So while I can see that it would make both philosophical, technical and
political sense to prioritise support for the more open systems above support
for proprietary ones, I don't think that policy should be pursued
over-zealously.  We _want_ users of proprietary systems to throw away their
proprietary tools and start using open ones and writing open code.

  Gcc and binutils both make a point of attempting to natively support a very
wide range of platforms for just this reason.  I think that GDB should be
attempting to target fairly much the same range.




    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: GDB is the GNU project's native debugger

[Ian Lance Taylor]

Andrew Cagney <cagney@gnu.org> writes:

> GDB is the GNU project's native debuger.  While we're certainly happy
> to accomodate people using GDB as either an embedded debugger or
> native debugger on other systems, the need to persue GDB as a native
> debugger on GNU systems must be our first priority.
> 
> Do we all agree with this?

While I think we all agree with this in some sense, I think you should
spell out where you are going with this.

For example, it would be easy to use this statement as the motivation
for removing features required for using gdb for embedded systems, or
on Windows.  I don't think that would be appropriate.

If you want to state that, where there is a direct and immediate
conflict between the needs of GNU systems and the needs of other
systems, the needs of the GNU systems take priority, I could support
that.

If you want to state that this applies to considerations of resources,
and of which parts of gdb to mark obsolescent, I could not support
that.

Ian

Re: GDB is the GNU project's native debugger

[Kris Warkentin]

Andrew Cagney wrote:

> GDB is the GNU project's native debuger.  While we're certainly happy 
> to accomodate people using GDB as either an embedded debugger or 
> native debugger on other systems, the need to persue GDB as a native 
> debugger on GNU systems must be our first priority.


How do you define GNU system?  If you're looking at the OS, Linux is the 
only GNU system in wide use since HURD is not mainstream.  If you define 
it as a system using a GNU toolchain then I don't see that you're 
particularily narrowing your scope since you now include many of the 
embedded systems, BSDs, some Win32 such as Cygwin and MinGW.

Could you perhaps tell us what you're trying to accomplish with this 
mission statement?  Are you looking to establish some sort of "level of 
support priority" system for deciding which new features to add and 
which bugs to fix?

cheers,

Kris

Re: GDB is the GNU project's native debugger

[Paul Breed]

>GDB is the GNU project's native debuger.  While we're certainly happy to 
>accomodate people using GDB as either an embedded debugger or native 
>debugger on other systems, the need to persue GDB as a native debugger on 
>GNU systems must be our first priority.
>
>Do we all agree with this?

I think that as many, if not more people use GDB for embedded development.
They may be under represented on this group, because they tend to be users 
of tools,
not developers of tools.

Paul

GDB is the GNU project's native debugger

[Andrew Cagney]

GDB is the GNU project's native debuger.  While we're certainly happy to 
accomodate people using GDB as either an embedded debugger or native 
debugger on other systems, the need to persue GDB as a native debugger 
on GNU systems must be our first priority.

Do we all agree with this?