Retiring in-tree GDB

[John Baldwin]

When this topic was last raised (by Warner I believe), the primary objection
(certainly my main one) was that the in-tree kgdb was the only kernel debugger
available. kgdb is now available via the devel/gdb port in ports (and as of
last week was enabled by default, so 'pkg install gdb' will get you a kgdb
binary). The kgdb in ports is in general superior to the one in the base
system. It is a cross debugger by default (and with my pending patches to
libkvm it even supports cross debugging of vmcores).

There are some issues still with devel/gdb: namely it does not currently
support some of the platforms supported by our in tree gdb such as arm and
mips. For these platforms I think the in-tree gdb will need to remain until
there is a suitable alternative.

However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default
to enabling lldb and disabling gdb for platforms that meet the following
criteria:

1) devel/gdb works including thread and kgdb support
2) lldb works

We could perhaps be more aggressive and handle lldb and gdb toggles
independently, but I think we want to ship some sort of userland debugger
out of the box on all of our platforms. The question I think might be if
we end up with platforms where 1) is true but 2) is not (such as powerpc).

I believe that these conditions are only true for x86 currently.

Comments?

[Ed Maste]

Post by John Baldwin
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default
to enabling lldb and disabling gdb for platforms that meet the following
1) devel/gdb works including thread and kgdb support
2) lldb works
We could perhaps be more aggressive and handle lldb and gdb toggles
independently, but I think we want to ship some sort of userland debugger
out of the box on all of our platforms. The question I think might be if
we end up with platforms where 1) is true but 2) is not (such as powerpc).
I believe that these conditions are only true for x86 currently.

For 11 I'd go further, and stop shipping the in-tree gdb if either 1
or 2 is true. Our in-tree gdb is over a decade old and has a number of
issues. I'm not sure there's much value in keeping it if 'pkg install
gdb' provides a gdb that's better in every way.

I'd suggest we do it in several steps, perhaps:

- Turn on lldb by default on amd64 (where it's at least as functional
as in-tree gdb) and on arm64 (where it's the most functional debugger
with FreeBSD support now).
- Send an announcement with the current status, information on the gdb
port, next steps, and to encourage testing of lldb on arm, powerpc,
and mips.
- Fix LLDB/i386 support
- Turn on lldb by default on remaining platforms (excluding sparc64,
which lacks support upstream)
- Fix remaining devel/gdb issues
- Turn off in-tree gdb on all platforms where either devel/gdb or lldb works

There is a Phabricator review open for the first step at
https://reviews.freebsd.org/D2

Post by John Baldwin
When this topic was last raised (by Warner I believe), the primary objection
(certainly my main one) was that the in-tree kgdb was the only kernel debugger
available. kgdb is now available via the devel/gdb port in ports (and as of
last week was enabled by default, so 'pkg install gdb' will get you a kgdb
binary). The kgdb in ports is in general superior to the one in the base
system. It is a cross debugger by default (and with my pending patches to
libkvm it even supports cross debugging of vmcores).
There are some issues still with devel/gdb: namely it does not currently
support some of the platforms supported by our in tree gdb such as arm and
mips. For these platforms I think the in-tree gdb will need to remain until
there is a suitable alternative.
Comments?
--
John Baldwin
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[Warner Losh]

Post by John Baldwin
There are some issues still with devel/gdb: namely it does not currently
support some of the platforms supported by our in tree gdb such as arm and
mips. For these platforms I think the in-tree gdb will need to remain until
there is a suitable alternative.

What’s the lift for adding mips and arm support? Can we leverage what we
have done for gcc/binutils ports at all and/or what we have in the tree today?

Post by John Baldwin
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default
to enabling lldb and disabling gdb for platforms that meet the following
1) devel/gdb works including thread and kgdb support
2) lldb works
We could perhaps be more aggressive and handle lldb and gdb toggles
independently, but I think we want to ship some sort of userland debugger
out of the box on all of our platforms. The question I think might be if
we end up with platforms where 1) is true but 2) is not (such as powerpc).
I believe that these conditions are only true for x86 currently.
Comments?

I think you are making this way too complicated.

I think we should just turn gdb off for all platforms. Leave it off by default.
For arm it’s an OK debugger, but not great. For mips it is barely usable
in its current state. So there’s not a huge loss in doing this.

For platforms where lldb works, turn it on.

Have devel/gdb available for as many platforms as it works on.

Warner

[Bryan Drewery]

Post by John Baldwin
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default

Disabling/removing gdb. Definitely. It is unusable in many cases and the
working gdb is just a 'pkg install' away.

Post by John Baldwin
to enabling lldb and disabling gdb for platforms that meet the following

Why should we include lldb in the base system? It is not needed to build
or use the system and we can easily provide one from packages.

Arguments about providing a default working system don't work here for
me as we don't provide perl, python, valgrind, vim, emacs, X11, etc. We
can provide lldb and gdb on the default DVD though.

If we are actually going to "package base" in 11, we should not be
adding new things into base that can easily live in ports. Yes, I know
lldb is already there but I don't think it should be.

Can the same be said for tools such as truss, ktrace or nvi? Sure. The
discussion is really "what packages should be installed by default".
The answer should be "what all, or most, users _need_" Do most users
need a debugger? I don't think so.

Post by John Baldwin
1) devel/gdb works including thread and kgdb support
2) lldb works

[Bryan Drewery]

Post by Bryan Drewery

Post by John Baldwin
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default

Disabling/removing gdb. Definitely. It is unusable in many cases and the
working gdb is just a 'pkg install' away.

Post by John Baldwin
to enabling lldb and disabling gdb for platforms that meet the following

Why should we include lldb in the base system? It is not needed to build
or use the system and we can easily provide one from packages.
Arguments about providing a default working system don't work here for
me as we don't provide perl, python, valgrind, vim, emacs, X11, etc. We
can provide lldb and gdb on the default DVD though.
If we are actually going to "package base" in 11, we should not be
adding new things into base that can easily live in ports. Yes, I know
lldb is already there but I don't think it should be.
Can the same be said for tools such as truss, ktrace or nvi? Sure. The
discussion is really "what packages should be installed by default".
The answer should be "what all, or most, users _need_" Do most users
need a debugger? I don't think so.

Post by John Baldwin
1) devel/gdb works including thread and kgdb support
2) lldb works

Other things to consider is that this increases build time for a tool
that only developers need. Given it is not a drop-in replacement for
gdb, a tool that people have become accustomed to over several decades,
the bar for adding it into the base system should be higher.

[Bryan Drewery]

Post by Bryan Drewery

Post by Bryan Drewery

Post by John Baldwin
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default

Disabling/removing gdb. Definitely. It is unusable in many cases and the
working gdb is just a 'pkg install' away.

Post by John Baldwin
to enabling lldb and disabling gdb for platforms that meet the following

Why should we include lldb in the base system? It is not needed to build
or use the system and we can easily provide one from packages.
Arguments about providing a default working system don't work here for
me as we don't provide perl, python, valgrind, vim, emacs, X11, etc. We
can provide lldb and gdb on the default DVD though.
If we are actually going to "package base" in 11, we should not be
adding new things into base that can easily live in ports. Yes, I know
lldb is already there but I don't think it should be.
Can the same be said for tools such as truss, ktrace or nvi? Sure. The
discussion is really "what packages should be installed by default".
The answer should be "what all, or most, users _need_" Do most users
need a debugger? I don't think so.

Post by John Baldwin
1) devel/gdb works including thread and kgdb support
2) lldb works

Other things to consider is that this increases build time for a tool
that only developers need. Given it is not a drop-in replacement for
gdb, a tool that people have become accustomed to over several decades,
the bar for adding it into the base system should be higher.

In private discussions it was pointed out we don't have reliable
packages for tier 2 architectures. That is a very valid point. I just
ask that we try to shift our mindset to "pkg install" where possible.

[Slawa Olhovchenkov]

Post by Bryan Drewery
Other things to consider is that this increases build time for a tool
that only developers need. Given it is not a drop-in replacement for
gdb, a tool that people have become accustomed to over several decades,
the bar for adding it into the base system should be higher.

Build time is wrong goal: end user don't need recompile system.
Right way: for general purpose (not embeded system and not kernel
developer) system don't need be recompiling. All features and tunuing
may be do by sysctl (prefer) or loader tunable. Tracking -STABLE may
be done in binary form, may be from private build server.

If you talk about recompile system and also talk "install compiler
package for system reompile" -- I am remeber badly Linux's time, with
incompatible combinations of kernel, userland, libc, compiler, package
manager and other hell.

[Ian Lepore]

Post by Bryan Drewery

Post by John Baldwin
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default

Disabling/removing gdb. Definitely. It is unusable in many cases and the
working gdb is just a 'pkg install' away.

Post by John Baldwin
to enabling lldb and disabling gdb for platforms that meet the following

Why should we include lldb in the base system? It is not needed to build
or use the system and we can easily provide one from packages.
Arguments about providing a default working system don't work here for
me as we don't provide perl, python, valgrind, vim, emacs, X11, etc.
We
can provide lldb and gdb on the default DVD though.
If we are actually going to "package base" in 11, we should not be
adding new things into base that can easily live in ports. Yes, I know
lldb is already there but I don't think it should be.
Can the same be said for tools such as truss, ktrace or nvi? Sure. The
discussion is really "what packages should be installed by default".
The answer should be "what all, or most, users _need_" Do most users
need a debugger? I don't think so.

Post by John Baldwin
1) devel/gdb works including thread and kgdb support
2) lldb works

This just-won't-die meme that a "functional system" is nothing more
than a bare kernel and an init binary and everything else comes from
ports is extra-scary when you consider that ports can't even be (cross
-)built for some architectures.

It sucks that the project is adopting the mindset that the only way to
compete with linux is to become linux. (And it sucks that installing a
truly functional system will require end users to have roughly the same
knowledge as the team that assembles a linux distro.)

-- Ian

[Bryan Drewery]

Post by Ian Lepore

Post by Bryan Drewery

Post by John Baldwin
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default

Disabling/removing gdb. Definitely. It is unusable in many cases and the
working gdb is just a 'pkg install' away.

Post by John Baldwin
to enabling lldb and disabling gdb for platforms that meet the following

Why should we include lldb in the base system? It is not needed to build
or use the system and we can easily provide one from packages.
Arguments about providing a default working system don't work here for
me as we don't provide perl, python, valgrind, vim, emacs, X11, etc.
We
can provide lldb and gdb on the default DVD though.
If we are actually going to "package base" in 11, we should not be
adding new things into base that can easily live in ports. Yes, I know
lldb is already there but I don't think it should be.
Can the same be said for tools such as truss, ktrace or nvi? Sure. The
discussion is really "what packages should be installed by default".
The answer should be "what all, or most, users _need_" Do most users
need a debugger? I don't think so.

Post by John Baldwin
1) devel/gdb works including thread and kgdb support
2) lldb works

This just-won't-die meme that a "functional system" is nothing more
than a bare kernel and an init binary and everything else comes from
ports is extra-scary when you consider that ports can't even be (cross
-)built for some architectures.
It sucks that the project is adopting the mindset that the only way to
compete with linux is to become linux. (And it sucks that installing a
truly functional system will require end users to have roughly the same
knowledge as the team that assembles a linux distro.)

It's not about Linux. It's about not providing the same thing twice on
the system. It's about not having 2 different compilers on the system.
Using ports on older releases means the base compiler is too outdated to
build from ports and is thus not used. We have so much redundancy before
/usr and /usr/local once you install packages or try to build from
ports. There's no sane reason for that.

In a world of a packaged base the default install should still mostly
match what we have now for POLA. Just that it is contained in packages.
My point here is that removing something is argument #1, adding
something is argument #2.

No one is seriously suggesting we provide a DVD with init, libc, rtld,
libthr and a kernel only. That may be "a package" which is considered
very critical and special, but it would be among many other packages.

Yes we need cross-compiling in ports. We also need more native build
servers in the cluster to provide packages.

[Slawa Olhovchenkov]

Post by Bryan Drewery

Post by Ian Lepore

Post by John Baldwin
1) devel/gdb works including thread and kgdb support
2) lldb works

This just-won't-die meme that a "functional system" is nothing more
than a bare kernel and an init binary and everything else comes from
ports is extra-scary when you consider that ports can't even be (cross
-)built for some architectures.
It sucks that the project is adopting the mindset that the only way to
compete with linux is to become linux. (And it sucks that installing a
truly functional system will require end users to have roughly the same
knowledge as the team that assembles a linux distro.)

It's not about Linux. It's about not providing the same thing twice on
the system. It's about not having 2 different compilers on the system.
Using ports on older releases means the base compiler is too outdated to
build from ports and is thus not used. We have so much redundancy before
/usr and /usr/local once you install packages or try to build from
ports. There's no sane reason for that.
In a world of a packaged base the default install should still mostly
match what we have now for POLA. Just that it is contained in packages.
My point here is that removing something is argument #1, adding
something is argument #2.
No one is seriously suggesting we provide a DVD with init, libc, rtld,
libthr and a kernel only. That may be "a package" which is considered
very critical and special, but it would be among many other packages.
Yes we need cross-compiling in ports. We also need more native build
servers in the cluster to provide packages.

Currently, ports, need to compile gcc49, have run depend of whole
gcc49.
This is not 'less compile'. And may cause many problems if outdated
compiler will be conflict with new compiler.

Base system now act as fixit bootrom: independed from application,
all-sufficient, full functional and always consistent.

[Mark Linimon]

Post by Ian Lepore
This just-won't-die meme that a "functional system" is nothing more
than a bare kernel and an init binary and everything else comes from
ports is extra-scary

I think this is an exaggeration.

IMHO it's a legitimate question to ask, "what is a minimal base system".

Note: I (have to) use debian at work. I was given the task "figure out
what parts of all this mess were installed by what, and which ones we
even need in the first place". I do not want to go there. It took me
days to do the forensics, and then script a build-from-scratch mode.

I do think we can ask "how many people need the test suite" and "how
many people need 3 firewalls".

I do not think we can ask "how many people need the base compiler".
Well, if asked, answered: all of them, if we want to keep being
FreeBSD.

mcl

[Julio Merino]

Post by Mark Linimon
I do not think we can ask "how many people need the base compiler".
Well, if asked, answered: all of them, if we want to keep being
FreeBSD.

And why would that be? What makes this FreeBSD?

Traditionally, a compiler has always been required because the only way to upgrade a BSD system was by recompiling it from source, and the only way to install extra software was by building it from ports. Things have changed: it's now possible to have a fully-functional, up-to-date system, with packages without ever compiling anything. Having a compiler in the base system is not a necessity any more (for amd64, at least).

No, I'm not in favor of removing the compiler from the base system; I think it has to stay for various other reasons. I'm just questioning the axiom you threw above.

What I'll argue is that subjecting the user to ever have to recompile anything, for the majority of use cases, is bad. And FreeBSD does not do this any longer: as mentioned above, it's now possible to have a functional system without compiling anything, so the compiler could now be optional.

Also, as a long-time NetBSD user, I was a bit surprised when I came to FreeBSD to find that the compiler tools were not optional. In NetBSD, the compiler tools have always been part of a comp.tgz set separate from base.tgz. Both are built from the source tree in unison, but when installing a new machine you can easily choose not to have comp.tgz. I have run lean servers without compilers for a long time, and it was just fine.

I guess we are off-topic now...

[Mark Linimon]

Post by Mark Linimon
I do not think we can ask "how many people need the base compiler".
Well, if asked, answered: all of them, if we want to keep being
FreeBSD.

Apparently I needed to make explicit "in my opinion".

mcl

[Slawa Olhovchenkov]

Post by Bryan Drewery

Post by John Baldwin
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default

Disabling/removing gdb. Definitely. It is unusable in many cases and the
working gdb is just a 'pkg install' away.

Post by John Baldwin
to enabling lldb and disabling gdb for platforms that meet the following

Why should we include lldb in the base system? It is not needed to build
or use the system and we can easily provide one from packages.
Arguments about providing a default working system don't work here for
me as we don't provide perl, python, valgrind, vim, emacs, X11, etc. We
can provide lldb and gdb on the default DVD though.
If we are actually going to "package base" in 11, we should not be
adding new things into base that can easily live in ports. Yes, I know
lldb is already there but I don't think it should be.
Can the same be said for tools such as truss, ktrace or nvi? Sure. The
discussion is really "what packages should be installed by default".
The answer should be "what all, or most, users _need_" Do most users
need a debugger? I don't think so.

When you need debuger you may don't have way to install it.

[Bryan Drewery]

Post by Slawa Olhovchenkov

Post by Bryan Drewery

Post by John Baldwin
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default

Disabling/removing gdb. Definitely. It is unusable in many cases and the
working gdb is just a 'pkg install' away.

Post by John Baldwin
to enabling lldb and disabling gdb for platforms that meet the following

Why should we include lldb in the base system? It is not needed to build
or use the system and we can easily provide one from packages.
Arguments about providing a default working system don't work here for
me as we don't provide perl, python, valgrind, vim, emacs, X11, etc. We
can provide lldb and gdb on the default DVD though.
If we are actually going to "package base" in 11, we should not be
adding new things into base that can easily live in ports. Yes, I know
lldb is already there but I don't think it should be.
Can the same be said for tools such as truss, ktrace or nvi? Sure. The
discussion is really "what packages should be installed by default".
The answer should be "what all, or most, users _need_" Do most users
need a debugger? I don't think so.

When you need debuger you may don't have way to install it.

How did you get a system?

DVD? 'pkg add /mnt/cd/packages/gdb.txz'
Network? 'pkg install gdb'

Fetching the packages to a USB drive from another system works too using
'pkg fetch -o'.

[Slawa Olhovchenkov]

Post by Bryan Drewery

Post by Slawa Olhovchenkov

Post by Bryan Drewery

Post by John Baldwin
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default

Disabling/removing gdb. Definitely. It is unusable in many cases and the
working gdb is just a 'pkg install' away.

Post by John Baldwin
to enabling lldb and disabling gdb for platforms that meet the following

Why should we include lldb in the base system? It is not needed to build
or use the system and we can easily provide one from packages.
Arguments about providing a default working system don't work here for
me as we don't provide perl, python, valgrind, vim, emacs, X11, etc. We
can provide lldb and gdb on the default DVD though.
If we are actually going to "package base" in 11, we should not be
adding new things into base that can easily live in ports. Yes, I know
lldb is already there but I don't think it should be.
Can the same be said for tools such as truss, ktrace or nvi? Sure. The
discussion is really "what packages should be installed by default".
The answer should be "what all, or most, users _need_" Do most users
need a debugger? I don't think so.

When you need debuger you may don't have way to install it.

How did you get a system?
DVD? 'pkg add /mnt/cd/packages/gdb.txz'
Network? 'pkg install gdb'
Fetching the packages to a USB drive from another system works too using
'pkg fetch -o'.

You talk about healty system.
System may be semi-broken and need some assistance to r/w mount, for
example.

[Bryan Drewery]

Post by Slawa Olhovchenkov

Post by Bryan Drewery

Post by Slawa Olhovchenkov

Post by Bryan Drewery

Post by John Baldwin
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default

Disabling/removing gdb. Definitely. It is unusable in many cases and the
working gdb is just a 'pkg install' away.

Post by John Baldwin
to enabling lldb and disabling gdb for platforms that meet the following

Why should we include lldb in the base system? It is not needed to build
or use the system and we can easily provide one from packages.
Arguments about providing a default working system don't work here for
me as we don't provide perl, python, valgrind, vim, emacs, X11, etc. We
can provide lldb and gdb on the default DVD though.
If we are actually going to "package base" in 11, we should not be
adding new things into base that can easily live in ports. Yes, I know
lldb is already there but I don't think it should be.
Can the same be said for tools such as truss, ktrace or nvi? Sure. The
discussion is really "what packages should be installed by default".
The answer should be "what all, or most, users _need_" Do most users
need a debugger? I don't think so.

When you need debuger you may don't have way to install it.

How did you get a system?
DVD? 'pkg add /mnt/cd/packages/gdb.txz'
Network? 'pkg install gdb'
Fetching the packages to a USB drive from another system works too using
'pkg fetch -o'.

You talk about healty system.
System may be semi-broken and need some assistance to r/w mount, for
example.

How does that relate to gdb?

I can only read your example as suggesting we need a /rescue/gdb too.

[Slawa Olhovchenkov]

Post by Bryan Drewery

Post by Slawa Olhovchenkov

Post by Bryan Drewery

Post by Slawa Olhovchenkov

Post by Bryan Drewery

Post by John Baldwin
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default

Disabling/removing gdb. Definitely. It is unusable in many cases and the
working gdb is just a 'pkg install' away.

Post by John Baldwin
to enabling lldb and disabling gdb for platforms that meet the following

Why should we include lldb in the base system? It is not needed to build
or use the system and we can easily provide one from packages.
Arguments about providing a default working system don't work here for
me as we don't provide perl, python, valgrind, vim, emacs, X11, etc. We
can provide lldb and gdb on the default DVD though.
If we are actually going to "package base" in 11, we should not be
adding new things into base that can easily live in ports. Yes, I know
lldb is already there but I don't think it should be.
Can the same be said for tools such as truss, ktrace or nvi? Sure. The
discussion is really "what packages should be installed by default".
The answer should be "what all, or most, users _need_" Do most users
need a debugger? I don't think so.

When you need debuger you may don't have way to install it.

How did you get a system?
DVD? 'pkg add /mnt/cd/packages/gdb.txz'
Network? 'pkg install gdb'
Fetching the packages to a USB drive from another system works too using
'pkg fetch -o'.

You talk about healty system.
System may be semi-broken and need some assistance to r/w mount, for
example.

How does that relate to gdb?

gdb related to kgdb? or kgdb is independed?
I am some time use kgdb for change some kernel variables, don't
controled by sysctl at that time.

Post by Bryan Drewery
I can only read your example as suggesting we need a /rescue/gdb too.

I am don't break system to this state, but may be /rescue/gdb will be good.

[John Baldwin]

Post by John Baldwin
When this topic was last raised (by Warner I believe), the primary objection
(certainly my main one) was that the in-tree kgdb was the only kernel debugger
available. kgdb is now available via the devel/gdb port in ports (and as of
last week was enabled by default, so 'pkg install gdb' will get you a kgdb
binary). The kgdb in ports is in general superior to the one in the base
system. It is a cross debugger by default (and with my pending patches to
libkvm it even supports cross debugging of vmcores).
There are some issues still with devel/gdb: namely it does not currently
support some of the platforms supported by our in tree gdb such as arm and
mips. For these platforms I think the in-tree gdb will need to remain until
there is a suitable alternative.
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default
to enabling lldb and disabling gdb for platforms that meet the following
1) devel/gdb works including thread and kgdb support
2) lldb works
We could perhaps be more aggressive and handle lldb and gdb toggles
independently, but I think we want to ship some sort of userland debugger
out of the box on all of our platforms. The question I think might be if
we end up with platforms where 1) is true but 2) is not (such as powerpc).
I believe that these conditions are only true for x86 currently.
Comments?

I believe I've fixed the one last thing that was depending on /usr/bin/gdb
(crashinfo) to use devel/gdb if it is present. I'd either like to disable
the base gdb on amd64 in the next week or so on HEAD, or perhaps if people are
really gutsy, disable it for all platforms on HEAD. We still don't have kgdb
in ports for non-x86 (though for ppc at least kgdb in ports and base is
equally dysfunctional).

However, to start with:

1) Does anyone have a reason to keep /usr/bin/gdb on amd64?

2) Does anyone have a reason to keep /usr/bin/gdb on !amd64?

[Sean Bruno]

Post by John Baldwin

Post by John Baldwin
When this topic was last raised (by Warner I believe), the primary objection
(certainly my main one) was that the in-tree kgdb was the only kernel debugger
available. kgdb is now available via the devel/gdb port in ports (and as of
last week was enabled by default, so 'pkg install gdb' will get you a kgdb
binary). The kgdb in ports is in general superior to the one in the base
system. It is a cross debugger by default (and with my pending patches to
libkvm it even supports cross debugging of vmcores).
There are some issues still with devel/gdb: namely it does not currently
support some of the platforms supported by our in tree gdb such as arm and
mips. For these platforms I think the in-tree gdb will need to remain until
there is a suitable alternative.
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default
to enabling lldb and disabling gdb for platforms that meet the following
1) devel/gdb works including thread and kgdb support
2) lldb works
We could perhaps be more aggressive and handle lldb and gdb toggles
independently, but I think we want to ship some sort of userland debugger
out of the box on all of our platforms. The question I think might be if
we end up with platforms where 1) is true but 2) is not (such as powerpc).
I believe that these conditions are only true for x86 currently.
Comments?

I believe I've fixed the one last thing that was depending on /usr/bin/gdb
(crashinfo) to use devel/gdb if it is present. I'd either like to disable
the base gdb on amd64 in the next week or so on HEAD, or perhaps if people are
really gutsy, disable it for all platforms on HEAD. We still don't have kgdb
in ports for non-x86 (though for ppc at least kgdb in ports and base is
equally dysfunctional).
1) Does anyone have a reason to keep /usr/bin/gdb on amd64?
2) Does anyone have a reason to keep /usr/bin/gdb on !amd64?

I don't have an immediate use case in the mips/mips64 case. Should
ports "just work" here or do I need some kind of "cross gdb"?

sean

[John Baldwin]

Post by Sean Bruno

Post by John Baldwin

Post by John Baldwin
When this topic was last raised (by Warner I believe), the primary objection
(certainly my main one) was that the in-tree kgdb was the only kernel debugger
available. kgdb is now available via the devel/gdb port in ports (and as of
last week was enabled by default, so 'pkg install gdb' will get you a kgdb
binary). The kgdb in ports is in general superior to the one in the base
system. It is a cross debugger by default (and with my pending patches to
libkvm it even supports cross debugging of vmcores).
There are some issues still with devel/gdb: namely it does not currently
support some of the platforms supported by our in tree gdb such as arm and
mips. For these platforms I think the in-tree gdb will need to remain until
there is a suitable alternative.
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default
to enabling lldb and disabling gdb for platforms that meet the following
1) devel/gdb works including thread and kgdb support
2) lldb works
We could perhaps be more aggressive and handle lldb and gdb toggles
independently, but I think we want to ship some sort of userland debugger
out of the box on all of our platforms. The question I think might be if
we end up with platforms where 1) is true but 2) is not (such as powerpc).
I believe that these conditions are only true for x86 currently.
Comments?

I believe I've fixed the one last thing that was depending on /usr/bin/gdb
(crashinfo) to use devel/gdb if it is present. I'd either like to disable
the base gdb on amd64 in the next week or so on HEAD, or perhaps if people are
really gutsy, disable it for all platforms on HEAD. We still don't have kgdb
in ports for non-x86 (though for ppc at least kgdb in ports and base is
equally dysfunctional).
1) Does anyone have a reason to keep /usr/bin/gdb on amd64?
2) Does anyone have a reason to keep /usr/bin/gdb on !amd64?

I don't have an immediate use case in the mips/mips64 case. Should
ports "just work" here or do I need some kind of "cross gdb"?

ports gdb does not yet work on mips. Once it supports mips it will work as
both a native and cross debugger, but it just doesn't know about FreeBSD/mips
at all. Does /usr/bin/gdb work on mips?

[Warner Losh]

Post by John Baldwin

Post by Sean Bruno

Post by John Baldwin

Post by John Baldwin
When this topic was last raised (by Warner I believe), the primary objection
(certainly my main one) was that the in-tree kgdb was the only kernel debugger
available. kgdb is now available via the devel/gdb port in ports (and as of
last week was enabled by default, so 'pkg install gdb' will get you a kgdb
binary). The kgdb in ports is in general superior to the one in the base
system. It is a cross debugger by default (and with my pending patches to
libkvm it even supports cross debugging of vmcores).
There are some issues still with devel/gdb: namely it does not currently
support some of the platforms supported by our in tree gdb such as arm and
mips. For these platforms I think the in-tree gdb will need to remain until
there is a suitable alternative.
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default
to enabling lldb and disabling gdb for platforms that meet the following
1) devel/gdb works including thread and kgdb support
2) lldb works
We could perhaps be more aggressive and handle lldb and gdb toggles
independently, but I think we want to ship some sort of userland debugger
out of the box on all of our platforms. The question I think might be if
we end up with platforms where 1) is true but 2) is not (such as powerpc).
I believe that these conditions are only true for x86 currently.
Comments?

I believe I've fixed the one last thing that was depending on /usr/bin/gdb
(crashinfo) to use devel/gdb if it is present. I'd either like to disable
the base gdb on amd64 in the next week or so on HEAD, or perhaps if people are
really gutsy, disable it for all platforms on HEAD. We still don't have kgdb
in ports for non-x86 (though for ppc at least kgdb in ports and base is
equally dysfunctional).
1) Does anyone have a reason to keep /usr/bin/gdb on amd64?
2) Does anyone have a reason to keep /usr/bin/gdb on !amd64?

I don't have an immediate use case in the mips/mips64 case. Should
ports "just work" here or do I need some kind of "cross gdb"?

ports gdb does not yet work on mips. Once it supports mips it will work as
both a native and cross debugger, but it just doesn't know about FreeBSD/mips
at all. Does /usr/bin/gdb work on mips?

It does, kinda. there’s a lot of stuff it gets right, so it can be useful. However,
there’s enough wrong that it’s super frustrating. So there’s a low bar to
replacement. If I can build a new /bin/cat and debug it with a ports gdb,
even if things are broken that kinda work now, I’m all for replacement.

If /usr/bin/gdb were super duper cool on mips, I’d have a different take, but
gdb on mips has never been stellar.

Warner

[John Baldwin]

Post by Warner Losh

Post by John Baldwin

Post by Sean Bruno

Post by John Baldwin

Post by John Baldwin
When this topic was last raised (by Warner I believe), the primary objection
(certainly my main one) was that the in-tree kgdb was the only kernel debugger
available. kgdb is now available via the devel/gdb port in ports (and as of
last week was enabled by default, so 'pkg install gdb' will get you a kgdb
binary). The kgdb in ports is in general superior to the one in the base
system. It is a cross debugger by default (and with my pending patches to
libkvm it even supports cross debugging of vmcores).
There are some issues still with devel/gdb: namely it does not currently
support some of the platforms supported by our in tree gdb such as arm and
mips. For these platforms I think the in-tree gdb will need to remain until
there is a suitable alternative.
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default
to enabling lldb and disabling gdb for platforms that meet the following
1) devel/gdb works including thread and kgdb support
2) lldb works
We could perhaps be more aggressive and handle lldb and gdb toggles
independently, but I think we want to ship some sort of userland debugger
out of the box on all of our platforms. The question I think might be if
we end up with platforms where 1) is true but 2) is not (such as powerpc).
I believe that these conditions are only true for x86 currently.
Comments?

I believe I've fixed the one last thing that was depending on /usr/bin/gdb
(crashinfo) to use devel/gdb if it is present. I'd either like to disable
the base gdb on amd64 in the next week or so on HEAD, or perhaps if people are
really gutsy, disable it for all platforms on HEAD. We still don't have kgdb
in ports for non-x86 (though for ppc at least kgdb in ports and base is
equally dysfunctional).
1) Does anyone have a reason to keep /usr/bin/gdb on amd64?
2) Does anyone have a reason to keep /usr/bin/gdb on !amd64?

I don't have an immediate use case in the mips/mips64 case. Should
ports "just work" here or do I need some kind of "cross gdb"?

ports gdb does not yet work on mips. Once it supports mips it will work as
both a native and cross debugger, but it just doesn't know about FreeBSD/mips
at all. Does /usr/bin/gdb work on mips?

It does, kinda. there’s a lot of stuff it gets right, so it can be useful. However,
there’s enough wrong that it’s super frustrating. So there’s a low bar to
replacement. If I can build a new /bin/cat and debug it with a ports gdb,
even if things are broken that kinda work now, I’m all for replacement.
If /usr/bin/gdb were super duper cool on mips, I’d have a different take, but
gdb on mips has never been stellar.

Well, devel/gdb won't work at all on mips, so if we removed /usr/bin/gdb on all
platforms you'd be left with no debugger at all. Starting with amd64 is probably
the most prudent for now. i386 is probably also a good candidate even without
working lldb.

[Adrian Chadd]

Hi,

We're missing a bunch of mips trapframe/etc handling code in the
upstream gdb for freebsd/mips. There's freebsd/alpha upstream, but not
mips.

i use the gdb in a qemu VM to diagnose freebsd/mips related issues.

I'm mainly afraid of having no sensible replacement - we can't (yet)
cross compile gdb easily for mips, we can't (yet) easily cross compile
a gdb /stub/ to remote debug mips, and upstream gdb / our port doesn't
support freebsd/mips.

If someone gdb cluey could pull out the freebsd/mips specific gdb code
and at least get it into the port as a set of patches, that'd be a
great start. I'm happy to try and work with others to get that
patchset upstreamed into gdb (once I finally sign the FSF
documentation, sigh.)

Thanks,



-adrian

[Slawa Olhovchenkov]

Post by John Baldwin

Post by John Baldwin
When this topic was last raised (by Warner I believe), the primary objection
(certainly my main one) was that the in-tree kgdb was the only kernel debugger
available. kgdb is now available via the devel/gdb port in ports (and as of
last week was enabled by default, so 'pkg install gdb' will get you a kgdb
binary). The kgdb in ports is in general superior to the one in the base
system. It is a cross debugger by default (and with my pending patches to
libkvm it even supports cross debugging of vmcores).
There are some issues still with devel/gdb: namely it does not currently
support some of the platforms supported by our in tree gdb such as arm and
mips. For these platforms I think the in-tree gdb will need to remain until
there is a suitable alternative.
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default
to enabling lldb and disabling gdb for platforms that meet the following
1) devel/gdb works including thread and kgdb support
2) lldb works
We could perhaps be more aggressive and handle lldb and gdb toggles
independently, but I think we want to ship some sort of userland debugger
out of the box on all of our platforms. The question I think might be if
we end up with platforms where 1) is true but 2) is not (such as powerpc).
I believe that these conditions are only true for x86 currently.
Comments?

I believe I've fixed the one last thing that was depending on /usr/bin/gdb
(crashinfo) to use devel/gdb if it is present. I'd either like to disable
the base gdb on amd64 in the next week or so on HEAD, or perhaps if people are
really gutsy, disable it for all platforms on HEAD. We still don't have kgdb
in ports for non-x86 (though for ppc at least kgdb in ports and base is
equally dysfunctional).
1) Does anyone have a reason to keep /usr/bin/gdb on amd64?
2) Does anyone have a reason to keep /usr/bin/gdb on !amd64?

lldb replace /usr/bin/gdb?
lldb still bundled with base system?

[John Baldwin]

Post by Slawa Olhovchenkov

Post by John Baldwin

Post by John Baldwin
When this topic was last raised (by Warner I believe), the primary objection
(certainly my main one) was that the in-tree kgdb was the only kernel debugger
available. kgdb is now available via the devel/gdb port in ports (and as of
last week was enabled by default, so 'pkg install gdb' will get you a kgdb
binary). The kgdb in ports is in general superior to the one in the base
system. It is a cross debugger by default (and with my pending patches to
libkvm it even supports cross debugging of vmcores).
There are some issues still with devel/gdb: namely it does not currently
support some of the platforms supported by our in tree gdb such as arm and
mips. For these platforms I think the in-tree gdb will need to remain until
there is a suitable alternative.
However, I would like to propose that we retire the in-tree GDB for some of
our platforms (namely x86) for 11. In particular, I think we should default
to enabling lldb and disabling gdb for platforms that meet the following
1) devel/gdb works including thread and kgdb support
2) lldb works
We could perhaps be more aggressive and handle lldb and gdb toggles
independently, but I think we want to ship some sort of userland debugger
out of the box on all of our platforms. The question I think might be if
we end up with platforms where 1) is true but 2) is not (such as powerpc).
I believe that these conditions are only true for x86 currently.
Comments?

I believe I've fixed the one last thing that was depending on /usr/bin/gdb
(crashinfo) to use devel/gdb if it is present. I'd either like to disable
the base gdb on amd64 in the next week or so on HEAD, or perhaps if people are
really gutsy, disable it for all platforms on HEAD. We still don't have kgdb
in ports for non-x86 (though for ppc at least kgdb in ports and base is
equally dysfunctional).
1) Does anyone have a reason to keep /usr/bin/gdb on amd64?
2) Does anyone have a reason to keep /usr/bin/gdb on !amd64?

lldb replace /usr/bin/gdb?
lldb still bundled with base system?

lldb is bundled on amd64 and arm. It does not include anything equivalent to
kgdb (yet), but you are also much better off using kgdb from ports anyway.