Re: /lib/foo.so.X -> /usr/lib/foo.so
Date: Thu, 4 Sep 2003 14:10:50 -0700 From: "David O'Brien" <[EMAIL PROTECTED]> On Thu, Sep 04, 2003 at 11:27:15PM +0300, Ruslan Ermilov wrote: > On Thu, Sep 04, 2003 at 09:58:39PM +0300, Ruslan Ermilov wrote: > [...] > > The patch is not a problem (attached). I've been looking at > > how our friends do this. NetBSD has symlinks in /usr/lib to > > /lib, both to .so and .so.X, and their cc(1) and ld(1) don't > > look things in /lib. Linux looks things up in both /lib and > > /usr/lib, and does not have symlinks from /usr/lib to /lib. > > > There is a sad typo above: Linux *does* have symlinks from > /usr/lib to /lib, so both use /usr/lib for linking. What version of Linux are you using? SuSE Enterprise Linux 8, and Red Hat Enterprise Linux 3 both do not have symlinks for libs from /usr/lib to /lib. They use a different machanism: suse# cat /usr/lib/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a ) Speaking as a (former) glibc developer (a true convert nowadays): Well, libc is a special case since there are a few functions that aren't provided by the shared libc, but are always linked statically. Linux does this to be compatible with the System V ABI. The whole thing is actually pointless since most interfaces in libc.so aren't compatible with the System V ABI, so it's nothing but a historical fart nowadays. Anyway, I think you'll see a symlink for /usr/lib/libm.so. At least my SuSE Linux 8.2 does have it. Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone ported HCF/HSF modem drivers to FreeBSD?
Date: Sun, 31 Aug 2003 15:02:36 -0700 (PDT) From: Nate Lawson <[EMAIL PROTECTED]> I asked this on -hackers a little while ago but no response. I'm curious if anyone has made an attempt to port these Winmodem drivers. http://www.linuxant.com/drivers/ I did look into it, but concluded that it was pretty hopeless. For starters, the DSP routines in there seem to need the FPU, and FreeBSD doesn't seem to allow that in the kernel. Apart from that, almost 100% of the code is in the binary-only modules, including a lot of Linux-specific code, which makes it very hard to see how the code is supposed to interface with the kernel. 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?
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. >relea
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?
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: [PATCH] Fix PT_IO ptrace(2) request
Date: Wed, 16 Oct 2002 12:49:14 -0400 (EDT) From: John Baldwin <[EMAIL PROTECTED]> On 14-Oct-2002 Mark Kettenis wrote: > The new PT_IO ptrace(2) request doesn't work, since it doesn't release > a lock. Since PT_IO is similar to PT_READ_D/PT_WRITE_D, I copied the > PROC_UNLOCK from there and inserted in the same location. Patch, > against version 1.103 of sys_process.c, attached. Good catch, I've committed it. Thanks! Thanks, I'll exploit the PT_IO stuff in the FSF GDB sources in the near future. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[PATCH] Fix PT_IO ptrace(2) request
The new PT_IO ptrace(2) request doesn't work, since it doesn't release a lock. Since PT_IO is similar to PT_READ_D/PT_WRITE_D, I copied the PROC_UNLOCK from there and inserted in the same location. Patch, against version 1.103 of sys_process.c, attached. This patch is also available as: http://members.chello.nl/~m.m.kettenis/FreeBSD/5-current/pt_io.patch. A bug report was filed using send-pr. It has ID kern/44065. Mark P.S. GDB will soon use this request for its data transfers if it is available. Really helps with large data transfers :-). Would be great if this problem would be fixed first though. We don't want GDB crashing the kernel, don't we ;-). --- /usr/src/sys/kern/sys_process.c.origWed Sep 11 10:13:54 2002 +++ /usr/src/sys/kern/sys_process.c Mon Oct 14 23:22:01 2002 @@ -647,6 +647,7 @@ kern_ptrace(struct thread *td, int req, return (error); case PT_IO: + PROC_UNLOCK(p); piod = addr; iov.iov_base = piod->piod_addr; iov.iov_len = piod->piod_len; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
