Re: GDB - do we dare?
Date: Sun, 13 Jul 2003 16:49:12 -0700 From: David O'Brien [EMAIL PROTECTED] On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote: Date: Fri, 11 Jul 2003 15:50:02 -0700 From: Marcel Moolenaar [EMAIL PROTECTED] Gang, With the gcc(1) dust not even settled yet, I like to get some feedback on gdb(1). AFAICT, this is the deal: o Both ia64 and amd64 need gdb(1) support before they can become a tier 1 platform. I think this implies upgrading to 5.3 the least. Upgrading to 5.3 for amd64 won't really help. While 5.3 included support for amd64, I'm told it is seriously broken. Since then, I've almost completely reworked GDB's amd64 target, to bring it in line with the i386 target, and adapt it to some major architectural changes in GDB. Based on that work, I've finished a FreeBSD/amd64 port yesterday. I'll try to get it on GDB's 6.0 release branch. However, backporting it to 5.3 would be a major PITA and IMHO a tremendous waste of effort. Not sure about that. I wish you would touch base with SuSE. AMD has had SuSE do quite a lot of work to make GDB 5.3 very usable on AMD64. I know there are parts of the work SuSE has yet to send to the GDB lists. I am worried that FreeBSD's AMD64 bits will be too different from the Linux ones and FreeBSD won't be able to leverage the work AMD is paying SuSE to do. I'll ask Andreas about it. Rest assured that FreeBSD will benefit from all the work that's being done on AMD64 Linux. I'm working closely with both Andreas and Michal from SuSE to get their work integrated as soon as possible although I've let some of the patches they submitted slip through the cracks. However, FreeBSD/sparc64 isn't properly supported in FSF GDB either. When Jason Thorpe added NetBSD/sparc64 support he did it very NetBSD specific rather than do it in a more general BSD/sparc64 way that all the BSD's could leverage. Generalizing his bits is needed in the FSF GDB bits. I noticed, and have been working on this. Following Jason's track isn't too difficult, and things can be made more generic rather easily. I'll try to get my work integrated before the 6.0 release. Unfortunately, GDB's sparc target has been unmaintained for quite some time now. Because of architectural changes in GDB the code has become a big mess of deprecated interfaces, and is almost unmaintainable right now. I'll do my best to improve things but I can't guarantee that all problems will be fixed before the 6.0 release. I'm not really familliar with the support for debugging FreeBSD kernels in GDB since that support is not in the FSF tree. Is there any chance that this code will be contributed back? Probably not, but I'd love it if you would take a look at it -- the times I've talked about to GDB guys hasn't been encouraging. How can we work to get the bits in /usr/src/gnu/usr.bin/binutils/gdb made part of stock FSF GDB (along with our diffs from the FSF vendor branch in /usr/src/contrib/gdb)? I've been snatching idea's from those places and incorporated them in the FSF sources already. For larger chunks of code the status of its copyright cleared up. Most of the code is definetly up to the standards, and could be integrated without major changes. I can do that. This would involve a copyright assignment, which could prove to be a major obstacle. We (I) can work to address this issue. Thanks. A2 I'm volunteering to help out here. As the i386 target maintainer and FreeBSD host/native maintainer, I seem to have sufficient background in GDB I guess ;-). For almost two years now, I've been using FreeBSD/i386 as my primary (development) platform, and I hope at least some people have noticed that the upstream GDB works much better on FreeBSD/i386 and FreeBSD/Alpha now. Now that I've got it working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot. Others may hate me for this, but getting stock GDB working on sparc64 is of higher priority as it is a Tier-1 platform and we have more sparc64 users than ia64. Or maybe, you can help back me on the gdb-patches mailing list and I can revive Jake's and my patches for sparc64. I'll try to do that. As I said above, I've already been doing some work, and I think I've most of the FreeBSD-specific code fleshed out now (sharing things common with NetBSD). But if you find anything missing after I check things in, I'll try to back you, and approve patches myself if necessary. releases, I'm dedicated to FreeBSD, and I'm certainly willing to do work on integrating new versions of GDB into the FreeBSD tree. I'm more than willing to mentor you what it takes to do a GDB import into FreeBSD. Thanks! Mark ___ [EMAIL PROTECTED] mailing list
Re: GDB - do we dare?
Date: Sat, 12 Jul 2003 13:39:30 -0700 From: Marcel Moolenaar [EMAIL PROTECTED] On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote: o We still have the Alpha gdb -k bug moved over from the 5.1 todo list to the 5.2 todo list. I think this is just a bug fix. I'm not really familliar with the support for debugging FreeBSD kernels in GDB since that support is not in the FSF tree. Is there any chance that this code will be contributed back? This would involve a copyright assignment, which could prove to be a major obstacle. The copyright of our kgdb support is already the FSF. See /usr/src/gnu/usr.bin/binutils/gdb/kvm-fbsd.c I'll have to find out whether the paperwork is actually there. The current support for debuggung libc_r-based threading is also not present in the FSF tree. So the question raised above applies here too. It looks to me that it can be contributed back. That would be great. I'm not really familiar with KSE, but AFAIK the kernel interfaces for debugging KSE's aren't there yet. I think that's mostly due to a knowledge gap. We just need people who can bridge between gdb and FreeBSD. Someone like you :-) o gdb(1) has created a 6.x branch, so it's likely that a new release is in the pipeline (within 6 months?). Upgrading to 5.3 may make a future upgrade easier due to smaller diffs and refreshed know-how. GDB 6.0 will defenitely be released before the end of the year :-). We're aiming at the end of August, but it will probably be somewhere in September. Interesting. It may even be possible to make gdb 6.0 part of FreeBSD 5.2 scheduling wise. Do we need a binutils update? We now have 2.13.2. Probably, yes. FSF GDB releases use a libbfd that's basically a snapshot taken at the point where the release branch was cut. You folks seem to try to get away with using libbfd from binutils. This usually works as long as the GDB and binutils releases used are not too far apart, so it's more likely that this works if binutils is updated. Actually, I think you'll need binutils 2.14 anyway for TLS. A1 If having support for amd64 is a major reason for doing a new import of GDB, importing the upcoming GDB 6.0 would make more sense to me. No ia64 is the major reason :-) Hmm. I think I just crashed pluto1 trying to get it to run the GDB testsuite on a not-yet-fully-functional GDB port. Currently RSE is giving me some headaches. A2 I'm volunteering to help out here. Cool, thanks. Shall we just create a p4 branch and start hacking? Oh dear, do I need to learn another version control system? Anyway, this can probably wait. I'll be on vacation from next tuesday until August 10, and I still have to do some work on the upstream GDB sources before I can start thinking about integrating things in the FreeBSD source tree. The GDB sparc target has suffered some bit rot, up to the point where it is hardly usable. better on FreeBSD/i386 and FreeBSD/Alpha now. Now that I've got it working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot. We probably need to talk then, because the ptrace interface needs to be fleshed out and I planned to do that while porting gdb. Probably. The current layout of `struct reg' and `struct fpreg' is a bit ... messy. Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GDB - do we dare?
On Sun, Jul 13, 2003 at 05:57:34PM +0200, Mark Kettenis wrote: A1 If having support for amd64 is a major reason for doing a new import of GDB, importing the upcoming GDB 6.0 would make more sense to me. No ia64 is the major reason :-) Hmm. I think I just crashed pluto1 trying to get it to run the GDB testsuite on a not-yet-fully-functional GDB port. Currently RSE is giving me some headaches. Yeah, this is known (both the crashes and the headache :-) I was working on that (the crashes), but now need to make ia64 functional again. The gcc import left us dead in the water. Our crt1.c is broken. A2 I'm volunteering to help out here. Cool, thanks. Shall we just create a p4 branch and start hacking? Oh dear, do I need to learn another version control system? Yes, preferrably. Using a p4 branch allows us to track the gdb 6 branch while we prepare for the import. It's a convenient place for people to grab the WIP. better on FreeBSD/i386 and FreeBSD/Alpha now. Now that I've got it working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot. We probably need to talk then, because the ptrace interface needs to be fleshed out and I planned to do that while porting gdb. Probably. The current layout of `struct reg' and `struct fpreg' is a bit ... messy. It is not. It is actually pretty neat. Incomplete maybe, but neat. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GDB - do we dare?
FSF GDB releases use a libbfd that's basically a snapshot taken at the point where the release branch was cut. Hmm, seems like a motivation for a libbfd port that tracks the snapshot, for this very reason. mcl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GDB - do we dare?
On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote: Date: Fri, 11 Jul 2003 15:50:02 -0700 From: Marcel Moolenaar [EMAIL PROTECTED] Gang, With the gcc(1) dust not even settled yet, I like to get some feedback on gdb(1). AFAICT, this is the deal: o Both ia64 and amd64 need gdb(1) support before they can become a tier 1 platform. I think this implies upgrading to 5.3 the least. Upgrading to 5.3 for amd64 won't really help. While 5.3 included support for amd64, I'm told it is seriously broken. Since then, I've almost completely reworked GDB's amd64 target, to bring it in line with the i386 target, and adapt it to some major architectural changes in GDB. Based on that work, I've finished a FreeBSD/amd64 port yesterday. I'll try to get it on GDB's 6.0 release branch. However, backporting it to 5.3 would be a major PITA and IMHO a tremendous waste of effort. Not sure about that. I wish you would touch base with SuSE. AMD has had SuSE do quite a lot of work to make GDB 5.3 very usable on AMD64. I know there are parts of the work SuSE has yet to send to the GDB lists. I am worried that FreeBSD's AMD64 bits will be too different from the Linux ones and FreeBSD won't be able to leverage the work AMD is paying SuSE to do. That said, giving the amount of work it takes to import a GDB release(snapshot) and get it working in our tree -- we really should import a 6.0 snapshot. However, FreeBSD/sparc64 isn't properly supported in FSF GDB either. When Jason Thorpe added NetBSD/sparc64 support he did it very NetBSD specific rather than do it in a more general BSD/sparc64 way that all the BSD's could leverage. Generalizing his bits is needed in the FSF GDB bits. I'm not really familliar with the support for debugging FreeBSD kernels in GDB since that support is not in the FSF tree. Is there any chance that this code will be contributed back? Probably not, but I'd love it if you would take a look at it -- the times I've talked about to GDB guys hasn't been encouraging. How can we work to get the bits in /usr/src/gnu/usr.bin/binutils/gdb made part of stock FSF GDB (along with our diffs from the FSF vendor branch in /usr/src/contrib/gdb)? This would involve a copyright assignment, which could prove to be a major obstacle. We (I) can work to address this issue. A2 I'm volunteering to help out here. As the i386 target maintainer and FreeBSD host/native maintainer, I seem to have sufficient background in GDB I guess ;-). For almost two years now, I've been using FreeBSD/i386 as my primary (development) platform, and I hope at least some people have noticed that the upstream GDB works much better on FreeBSD/i386 and FreeBSD/Alpha now. Now that I've got it working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot. Others may hate me for this, but getting stock GDB working on sparc64 is of higher priority as it is a Tier-1 platform and we have more sparc64 users than ia64. Or maybe, you can help back me on the gdb-patches mailing list and I can revive Jake's and my patches for sparc64. releases, I'm dedicated to FreeBSD, and I'm certainly willing to do work on integrating new versions of GDB into the FreeBSD tree. I'm more than willing to mentor you what it takes to do a GDB import into FreeBSD. Enjoy! -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GDB - do we dare?
On Sun, Jul 13, 2003 at 05:57:34PM +0200, Mark Kettenis wrote: Date: Sat, 12 Jul 2003 13:39:30 -0700 From: Marcel Moolenaar [EMAIL PROTECTED] On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote: o We still have the Alpha gdb -k bug moved over from the 5.1 todo list to the 5.2 todo list. I think this is just a bug fix. I'm not really familliar with the support for debugging FreeBSD kernels in GDB since that support is not in the FSF tree. Is there any chance that this code will be contributed back? This would involve a copyright assignment, which could prove to be a major obstacle. The copyright of our kgdb support is already the FSF. See /usr/src/gnu/usr.bin/binutils/gdb/kvm-fbsd.c I'll have to find out whether the paperwork is actually there. As you know I do have paperwork on file, which covers some of the work. The bigger question is will the fuctionality get resistance to being part of the FSF GDB? Can you evaluate the FreeBSD additions from that point of view? Interesting. It may even be possible to make gdb 6.0 part of FreeBSD 5.2 scheduling wise. Do we need a binutils update? We now have 2.13.2. Please, don't even worry about that. You'll get lost in a non-issue. The real issue is getting a patch that would update our bits to GDB 6.0 -- not the actual integration. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GDB - do we dare?
On Sun, Jul 13, 2003 at 02:28:08PM -0500, Mark Linimon wrote: FSF GDB releases use a libbfd that's basically a snapshot taken at the point where the release branch was cut. Hmm, seems like a motivation for a libbfd port that tracks the snapshot, for this very reason. NO! -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GDB - do we dare?
Marcel Moolenaar wrote: I'd say: upgrade gdb(1) and add support for ia64 and amd64, as well as make sure we fix any known showstopper bugs we know of. [ ... ] Thoughts? Will remote source level kernel debugging continue to work? -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GDB - do we dare?
Date: Fri, 11 Jul 2003 15:50:02 -0700 From: Marcel Moolenaar [EMAIL PROTECTED] Gang, With the gcc(1) dust not even settled yet, I like to get some feedback on gdb(1). AFAICT, this is the deal: o Both ia64 and amd64 need gdb(1) support before they can become a tier 1 platform. I think this implies upgrading to 5.3 the least. Upgrading to 5.3 for amd64 won't really help. While 5.3 included support for amd64, I'm told it is seriously broken. Since then, I've almost completely reworked GDB's amd64 target, to bring it in line with the i386 target, and adapt it to some major architectural changes in GDB. Based on that work, I've finished a FreeBSD/amd64 port yesterday. I'll try to get it on GDB's 6.0 release branch. However, backporting it to 5.3 would be a major PITA and IMHO a tremendous waste of effort. o We still have the Alpha gdb -k bug moved over from the 5.1 todo list to the 5.2 todo list. I think this is just a bug fix. I'm not really familliar with the support for debugging FreeBSD kernels in GDB since that support is not in the FSF tree. Is there any chance that this code will be contributed back? This would involve a copyright assignment, which could prove to be a major obstacle. o With libkse and libthr in the tree, we probably want to keep close to the latest gdb(1) development to benefit from the threading work that's likely to be done and also make sure we add whatever we need to support our threading models. The current support for debuggung libc_r-based threading is also not present in the FSF tree. So the question raised above applies here too. Note that there isn't much development on thread-related GDB stuff. The Linux folks are still chasing bugs, mainly because there are no sane kernel interfaces for debugging threads and the kernel interfaces keep changing. I'm confident we can avoid that mess on FreeBSD ;-). I'm not really familiar with KSE, but AFAIK the kernel interfaces for debugging KSE's aren't there yet. o The new gcc(1) also adds support for TLS, which, if time is with us may be supported by both libkse and libthr before R5.2 and may need some gdb(1) support as well. I don't know, but if it does, we probably want to add that to gdb 5.3 or later. It's already working on Linux, so it should be easy to add support for TLS for other platforms. o gdb(1) has created a 6.x branch, so it's likely that a new release is in the pipeline (within 6 months?). Upgrading to 5.3 may make a future upgrade easier due to smaller diffs and refreshed know-how. GDB 6.0 will defenitely be released before the end of the year :-). We're aiming at the end of August, but it will probably be somewhere in September. I think the diffs between 5.2 and 5.3 are negligible compared to the the diffs between 5.3 and 6.0, at least for i386/amd64 and Alpha. I'd say: upgrade gdb(1) and add support for ia64 and amd64, as well as make sure we fix any known showstopper bugs we know of. Q1 How does that sound in general? Q2 Do we have people with sufficient background and motivation who want to volunteer to make this happen? Since the answer to Q2 is likely no or indetermined, I would like to emphasize that I do not expect this to be a one-man show. We really need to treat this as a project. Thoughts? A1 If having support for amd64 is a major reason for doing a new import of GDB, importing the upcoming GDB 6.0 would make more sense to me. A2 I'm volunteering to help out here. As the i386 target maintainer and FreeBSD host/native maintainer, I seem to have sufficient background in GDB I guess ;-). For almost two years now, I've been using FreeBSD/i386 as my primary (development) platform, and I hope at least some people have noticed that the upstream GDB works much better on FreeBSD/i386 and FreeBSD/Alpha now. Now that I've got it working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot. Although my primary development will be focussed on the upstream FSF GDB releases, I'm dedicated to FreeBSD, and I'm certainly willing to do work on integrating new versions of GDB into the FreeBSD tree. Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GDB - do we dare?
On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote: o We still have the Alpha gdb -k bug moved over from the 5.1 todo list to the 5.2 todo list. I think this is just a bug fix. I'm not really familliar with the support for debugging FreeBSD kernels in GDB since that support is not in the FSF tree. Is there any chance that this code will be contributed back? This would involve a copyright assignment, which could prove to be a major obstacle. The copyright of our kgdb support is already the FSF. See /usr/src/gnu/usr.bin/binutils/gdb/kvm-fbsd.c The current support for debuggung libc_r-based threading is also not present in the FSF tree. So the question raised above applies here too. It looks to me that it can be contributed back. I'm not really familiar with KSE, but AFAIK the kernel interfaces for debugging KSE's aren't there yet. I think that's mostly due to a knowledge gap. We just need people who can bridge between gdb and FreeBSD. Someone like you :-) o gdb(1) has created a 6.x branch, so it's likely that a new release is in the pipeline (within 6 months?). Upgrading to 5.3 may make a future upgrade easier due to smaller diffs and refreshed know-how. GDB 6.0 will defenitely be released before the end of the year :-). We're aiming at the end of August, but it will probably be somewhere in September. Interesting. It may even be possible to make gdb 6.0 part of FreeBSD 5.2 scheduling wise. Do we need a binutils update? We now have 2.13.2. A1 If having support for amd64 is a major reason for doing a new import of GDB, importing the upcoming GDB 6.0 would make more sense to me. No ia64 is the major reason :-) A2 I'm volunteering to help out here. Cool, thanks. Shall we just create a p4 branch and start hacking? better on FreeBSD/i386 and FreeBSD/Alpha now. Now that I've got it working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot. We probably need to talk then, because the ptrace interface needs to be fleshed out and I planned to do that while porting gdb. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
