Re: crypto(9) choose another driver if we cannot open a session on it
Le Wed, 10 Dec 2008 14:50:51 -0800, Sam Leffler a écrit : Hello, > > Which code exactly? Yes I'm curious :-) > > > > I'm thinking about how to remove the need for a device to support > > all the algorithms when we open a session. By using a fake "crypto > > virtual device" to open and dispatch crypto requests to real > > devices or to cryptosoft. But i don't have any code to show yet. > > > > There is one thing I'm asking about crypto(9): > > - I doubt that the migration of a session is safe and I think that > > would be far easier to prevent a driver to unregister when there are > > some pending sessions on it? glxsb and padlock do not allow to > > unregister in this case. > > > > I've looked quickly the code of geli or ipsec. If the crypto > > framework returns EAGAIN because the migration of the session, they > > restart a crypto_dispatch(crp) but the datas in crp->crp_buf can be > > corrupted by the previous crypto operation (IMHO, may be i've missed > > something)? > > > This sounds like the session management layer I wanted to insert a > while back. It was a reason why I made the s/w driver into a pseudo > device (so there'd be a handle). That is the easiest way to do, i think. > As to unregister that was designed for devices like cardbus cards > that might go away. About the only way to simulate it today is to > unload a driver module. But it should work; if you see an issue we > should try to fix it. Ok, thank you. I will try to tests it. > OTOH the limitations of the existing crypto > code are dramatic and the rationale for maintaining the obsd api's > (both in kernel and user space) are no longer valid. It would be > good to see someone take this stuff and overhaul it to do things like: > > o add a session management layer that falls back to s/w when a device >is incapable and when operations are more efficiently done in s/w > (e.g ops too small to incur the dma setup/overhead) > o do load balancing over multiple devices > o support cpu resources as pseudo drivers (e.g. pin a thread to a cpu) > o replace the bogus fd session crud w/ device cloning > > The linux folks have done some of this and there may be lessons to be > learned from their efforts. FWIW netbsd has some recent user api > changes for doing async ops and batching to speedup openssl etc; if > you're going to get into this stuff you might take a look. I don't know enough the kernel to make a revolution. Anyway I can make some evolutions and try to help. Is there someone working on the crypto framework ? Regards. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Strange "changed paths" in svn commits
On Fri, Dec 12, 2008 at 08:21:25AM -0800, Tim Kientzle wrote: > Rick C. Petty wrote: > >On Fri, Dec 12, 2008 at 01:15:17PM +0200, Artis Caune wrote: > > > >I suspect you've run into a well-known svn bug that affects "svn merge". I > >thought they had fixed it with subversion 1.5.4, but apparently it's still > >around. When doing a merge, it seems to randomly touch a bunch of files.. > >it only updates the svn:mergeinfo property on those files ... > > I've seen this happen only once and eventually figured > out that I had a partial checkout underneath the merge point. > It was especially confusing in my case because I actually > had a complete checkout---nothing was missing---but > one of the directories was marked "depth=immediates" > so it was treated as a partial checkout. > > If the svn:mergeinfo has asterisks in it, this is why. In my case, I had a fresh copy that I merged a single file into, but it touched 5 other random files; files I had never seen, much less ever edited. We've seen this behavior for weeks, but the rate of occurances dropped significantly with svn 1.5.4-- dropped, not disappeared completely. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: preventing FIFO from EOF
BTW, buffer was written way back when memory was measured in kilobytes and the ethernet was 10 mgb, so things have changed a bit, and its effectivness is questionable :-) My scenario: prog1 | prog2 where both are daemons. prog1 does all the work, and sends commands for prog2 to do when needed. I don't want prog1 to block while prog2 is busy executing the command. So a buffer is inserted between the two: prog1 | buffer | prog2 Asynchronous execution of commands. It's as simple as that. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: preventing FIFO from EOF
Christoph Mallon wrote: rihad schrieb: $ mkfifo /var/tmp/foo $ buffer -i /var/tmp/foo# misc/buffer # in another console: $ echo hi > /var/tmp/foo buffer prints hi and exits. I want it to keep reading and printing indefinitely. Further experimentation revealed that I need two writers: one dummy writer that just keeps /var/tmp/foo open for writing, and the other doing the "real work". This way buffer wouldn't exit. But how to emulate the dummy writer? It itself needs to block on something to keep /var/tmp/foo open. Any clean way to do this in shell? Maybe the solution is quite simple but isn't at the tip of my tongue. Maybe "tail -f" is what you are looking for. You mean in place of buffer? buffer is there for a reason (so that writers never block). Something as simple as this: $ sh < /dev/null > /var/tmp/kick 2>/dev/null seems to block indefinitely, but exits as soon as I run $ buffer -i /var/tmp/foo (and buffer exits too) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: preventing FIFO from EOF
Christoph Mallon wrote: rihad schrieb: Something as simple as this: $ sh < /dev/null > /var/tmp/kick 2>/dev/null seems to block indefinitely, but exits as soon as I run $ buffer -i /var/tmp/foo (and buffer exits too) Strangely enough, something as stupid as this does the trick: sh < /dev/stdout > /var/tmp/kick 2>/dev/null i.e. reading from stdout blocks. Now sh keeps buffer block on /var/tmp/kick and never exit ;) I'm not sure what this does or why and how it works Unix-wise. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: preventing FIFO from EOF
Danny Braniss wrote: $ mkfifo /var/tmp/foo $ buffer -i /var/tmp/foo# misc/buffer # in another console: $ echo hi > /var/tmp/foo buffer prints hi and exits. I want it to keep reading and printing indefinitely. Further experimentation revealed that I need two writers: one dummy writer that just keeps /var/tmp/foo open for writing, and the other doing the "real work". This way buffer wouldn't exit. But how to emulate the dummy writer? It itself needs to block on something to keep /var/tmp/foo open. Any clean way to do this in shell? Maybe the solution is quite simple but isn't at the tip of my tongue. Thanks. too easy n csh: while 1 buffer -i /var/tmp/foo end or in sh: while true; do buffer -i /var/tmp/foo done Thanks, but I should have said that buffer must always run to never miss any data. The reason being that buffer's output gets fed into another program that shouldn't be restarted. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: preventing FIFO from EOF
Danny Braniss wrote: $ mkfifo /var/tmp/foo $ buffer -i /var/tmp/foo# misc/buffer # in another console: $ echo hi > /var/tmp/foo buffer prints hi and exits. I want it to keep reading and printing indefinitely. Further experimentation revealed that I need two writers: one dummy writer that just keeps /var/tmp/foo open for writing, and the other doing the "real work". This way buffer wouldn't exit. But how to emulate the dummy writer? It itself needs to block on something to keep /var/tmp/foo open. Any clean way to do this in shell? Maybe the solution is quite simple but isn't at the tip of my tongue. Thanks. too easy n csh: while 1 buffer -i /var/tmp/foo end or in sh: while true; do buffer -i /var/tmp/foo done Thanks, but I should have said that buffer must always run to never miss any data. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: preventing FIFO from EOF
> > BTW, buffer was written way back when memory was measured > > in kilobytes and the ethernet was 10 mgb, so things have changed a bit, and > > its effectivness is questionable :-) > > > My scenario: > > prog1 | prog2 > > where both are daemons. prog1 does all the work, and sends commands for > prog2 to do when needed. I don't want prog1 to block while prog2 is busy > executing the command. So a buffer is inserted between the two: > > prog1 | buffer | prog2 > > Asynchronous execution of commands. It's as simple as that. ahh, but you see, you have now 4 processes, which the scheduler has no real reason to treat specialy, each can block. Then again, I have no idea how much data you are moving around, and how fast you need to process it. buffer was designed to keep a magnetic tape writing at full speed - streaming, or at least for some longer time. then again, there is nothing better than trying it out, instead of out guessing the os :-) cheers, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Strange "changed paths" in svn commits
Rick C. Petty wrote: On Fri, Dec 12, 2008 at 01:15:17PM +0200, Artis Caune wrote: I suspect you've run into a well-known svn bug that affects "svn merge". I thought they had fixed it with subversion 1.5.4, but apparently it's still around. When doing a merge, it seems to randomly touch a bunch of files.. it only updates the svn:mergeinfo property on those files ... I've seen this happen only once and eventually figured out that I had a partial checkout underneath the merge point. It was especially confusing in my case because I actually had a complete checkout---nothing was missing---but one of the directories was marked "depth=immediates" so it was treated as a partial checkout. If the svn:mergeinfo has asterisks in it, this is why. Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: preventing FIFO from EOF
> Danny Braniss wrote: > >> $ mkfifo /var/tmp/foo > >> $ buffer -i /var/tmp/foo# misc/buffer > >> # in another console: > >> $ echo hi > /var/tmp/foo > >> > >> buffer prints hi and exits. I want it to keep reading and printing > >> indefinitely. > >> > >> Further experimentation revealed that I need two writers: one dummy > >> writer that just keeps /var/tmp/foo open for writing, and the other > >> doing the "real work". This way buffer wouldn't exit. But how to emulate > >> the dummy writer? It itself needs to block on something to keep > >> /var/tmp/foo open. Any clean way to do this in shell? Maybe the solution > >> is quite simple but isn't at the tip of my tongue. > >> > >> Thanks. > > > > too easy > > n csh: > > while 1 > > buffer -i /var/tmp/foo > > end > > or in sh: > > while true; do > > buffer -i /var/tmp/foo > > done > > > > > Thanks, but I should have said that buffer must always run to never miss > > any data. > > The reason being that buffer's output gets fed into another program that > shouldn't be restarted. use 'tail -f' instead of 'buffer -i' then, or place the while in file and execute that. BTW, buffer was written way back when memory was measured in kilobytes and the ethernet was 10 mgb, so things have changed a bit, and its effectivness is questionable :-) danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Strange "changed paths" in svn commits
On Fri, Dec 12, 2008 at 01:15:17PM +0200, Artis Caune wrote: > Hi, > > Is it how merging works or I'm missing something? I suspect you've run into a well-known svn bug that affects "svn merge". I thought they had fixed it with subversion 1.5.4, but apparently it's still around. When doing a merge, it seems to randomly touch a bunch of files.. it only updates the svn:mergeinfo property on those files, but it's still annoying. Whenever I do a merge, I always merge into a working copy, then double-check the work with "svn diff" before committing. When I see it bring in extra files, I just do a revert on those, then the commit is clean. I'm hoping the tigris folks are working on this issue. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: NFS (& amd?) dysfunction descending a hierarchy
On Fri, Dec 12, 2008 at 03:41:29PM +0200, Kostik Belousov wrote: > ... > > * At 1229033597.287187 it issues an fstatfs() against FD 4; the > > unsuccessful return is at 1229033597.287195, claiming ENOENT. > > > > Say WHAT??!? > ... > > But is this error transient or permanent ? I.e., would restart of rm > successful or failing ? In a test yesterday, it took 3 attempts (each attempt being an invocations of "rm -fr ~bspace/ports") to actually complete removal of the hierarchy. Please note that: * Done on a locally-mounted file systen (vs. NFS), a single invocation is sufficient and terminates normally. Each of the above-cited attempts but the last terminated with a status code of 1 (as well as a whine that one or more subdirectories was not empty -- this, as a result of "rm" getting inconsistent information about the status of the file system). * Done on either a locally- or NFS-mounted file system in FreeBSD 6.x, a single invocation is sufficient and terminates normally. In other words, this is a regression. > Anyway, this error looks different too. ? From the earlier-posted results in 7.x? Not that I can tell. In each case, the amd(8) child process is forked to attempt an unmount(), tries it, gets EBUSY, and exits. Meanwhile, rm(1) is descending a directory tree. It had performed a readdir(), and had been unlinking files and performing rmdir() against empty subdirectories. It encounters an entry, issues stat(), finds that it's a subdirectory, open()s it, gets an FD, issues fstat(), gets results that match those of the earlier stat(), issues fcntl() against the FD (which returns 0), tries to issue fstatfs() against the FD *that is still open*, and gets told ENOENT. It does differ from the behavior in 8-CURRENT, in that the amd(8) child process in 8-CURRENT does not appear to get EBUSY. The behavior from rm(1)'s perspective is very similar, though. If it would help, I could try getting a ktrace from a 6.x system, but I expect it will be very boring: the amd(8) child process should get EBUSY (as it does in 7.x), and nothing else should happen, since the unmount() attempt failed. And since it failed, rm(1) doesn't get told inconsistent information, so things Just Work. I admit that I'm no expert on VFS or much of the rest of the kernel, for that matter. But what I have observed happening in recent 7.x is both wrong and a regression. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpNoDLDaFr3Z.pgp Description: PGP signature
Re: preventing FIFO from EOF
rihad schrieb: $ mkfifo /var/tmp/foo $ buffer -i /var/tmp/foo# misc/buffer # in another console: $ echo hi > /var/tmp/foo buffer prints hi and exits. I want it to keep reading and printing indefinitely. Further experimentation revealed that I need two writers: one dummy writer that just keeps /var/tmp/foo open for writing, and the other doing the "real work". This way buffer wouldn't exit. But how to emulate the dummy writer? It itself needs to block on something to keep /var/tmp/foo open. Any clean way to do this in shell? Maybe the solution is quite simple but isn't at the tip of my tongue. Maybe "tail -f" is what you are looking for. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: NFS (& amd?) dysfunction descending a hierarchy
On Thu, Dec 11, 2008 at 02:53:49PM -0800, David Wolfskill wrote:
> On Wed, Dec 10, 2008 at 07:06:20PM +0200, Kostik Belousov wrote:
> > ...
> > > What concerns me is that even if the attempted unmount gets EBUSY, the
> > > user-level process descending the directory hierarchy is getting ENOENT
> > > trying to issue fstatfs() against an open file descriptor.
> > >
> > > I'm having trouble figuring out any way that makes any sense.
> >
> > Basically, the problem is that NFS uses shared lookup, and this allows
> > for the bug where several negative namecache entries are created for
> > non-existent node. Then this node gets created, removing only the first
> > negative namecache entry. For some reasons, vnode is reclaimed; amd'
> > tasting of unmount is a good reason for vnode to be reclaimed.
> >
> > Now, you have existing path and a negative cache entry. This was
> > reported by Peter Holm first, I listed relevant revisions that
> > should fix this in previous mail.
>
> Well, I messed up the machine I had been using for testing, and needed
> to wait for IT to do something to it since I don't have physical or
> console access to it.
>
> So after I happened to demonstrate the effect using my desktop -- which
> had been running RELENG_7_1, sources updated as of around 0400 hrs.
> US/Pacific -- I decided to go ahead and update the desktop to RELENG_7_1
> as of this morning (which had the commit to sys/kern/vfs_cache.c), then
> test.
>
> It still failed, apparently in the same way; details below.
>
> First, here's a list of the files that were changed:
>
> U lib/libarchive/archive_read_support_format_iso9660.c
> U lib/libarchive/archive_string.c
> U lib/libarchive/archive_string.h
> U lib/libc/gen/times.3
> U lib/libc/i386/sys/pipe.S
> U lib/libc/i386/sys/reboot.S
> U lib/libc/i386/sys/setlogin.S
> U lib/libutil/Makefile
> U lib/libutil/kinfo_getfile.c
> U lib/libutil/kinfo_getvmmap.c
> U lib/libutil/libutil.h
> U share/man/man4/bce.4
> U share/man/man5/Makefile
> U share/man/man5/fstab.5
> U share/man/man5/nullfs.5
> U sys/amd64/Makefile
> U sys/boot/forth/loader.conf.5
> U sys/dev/ale/if_ale.c
> U sys/dev/bce/if_bce.c
> U sys/dev/cxgb/cxgb_main.c
> U sys/dev/cxgb/common/cxgb_ael1002.c
> U sys/dev/cxgb/common/cxgb_t3_hw.c
> U sys/dev/cxgb/common/cxgb_xgmac.c
> U sys/dev/re/if_re.c
> U sys/fs/nullfs/null_vnops.c
> U sys/kern/Make.tags.inc
> U sys/kern/kern_descrip.c
> U sys/kern/kern_proc.c
> U sys/kern/vfs_cache.c
> U sys/netinet/in_pcb.h
> U sys/pci/if_rlreg.h
> U sys/sys/sysctl.h
> U sys/sys/user.h
> U sys/ufs/ufs/ufs_quota.c
> U usr.bin/procstat/Makefile
> U usr.bin/procstat/procstat_files.c
> U usr.bin/procstat/procstat_vm.c
> U usr.bin/tar/util.c
> U usr.bin/tar/test/Makefile
> U usr.bin/tar/test/test_strip_components.c
> U usr.bin/tar/test/test_symlink_dir.c
> U usr.bin/xargs/xargs.1
> U usr.sbin/mtree/mtree.c
>
> We see that sys/kern/vfs_cache.c is, indeed, among them. And:
>
> dwolf-bsd(7.1-P)[5] grep '\$FreeBSD' /sys/kern/vfs_cache.c
> __FBSDID("$FreeBSD: src/sys/kern/vfs_cache.c,v 1.114.2.3 2008/12/09 16:20:58
> kib Exp $");
> dwolf-bsd(7.1-P)[6]
>
> That should correspond to the desired version of the file.
>
> Here we see an excerpt from the ktrace output for the amd(8) process and
> its children; this is a point when amd(8) is trying an unmount() to see
> if it can get away with it:
>
>977 amd 1229033597.269612 CALL gettimeofday(0x807ad48,0)
>977 amd 1229033597.269620 RET gettimeofday 0
>977 amd 1229033597.269630 CALL
> sigprocmask(SIG_BLOCK,0xbfbfeaec,0xbfbfeadc)
>977 amd 1229033597.269637 RET sigprocmask 0
>977 amd 1229033597.269645 CALL fork
>977 amd 1229033597.273810 RET fork 1712/0x6b0
> 1712 amd 1229033597.273811 RET fork 0
>977 amd 1229033597.273836 CALL sigprocmask(SIG_SETMASK,0xbfbfeadc,0)
> 1712 amd 1229033597.273845 CALL getpid
>977 amd 1229033597.273850 RET sigprocmask 0
> 1712 amd 1229033597.273855 RET getpid 1712/0x6b0
>977 amd 1229033597.273864 CALL gettimeofday(0x807ad48,0)
>977 amd 1229033597.273874 RET gettimeofday 0
> 1712 amd 1229033597.273878 CALL unmount(0x2832c610,0)
> ...
> 1712 amd 1229033597.352643 RET unmount -1 errno 16 Device busy
> 1712 amd 1229033597.352695 CALL
> sigprocmask(SIG_BLOCK,0x28097c00,0xbfbfea0c)
> 1712 amd 1229033597.352728 RET sigprocmask 0
> 1712 amd 1229033597.352751 CALL sigprocmask(SIG_SETMASK,0x28097c10,0)
> 1712 amd 1229033597.352769 RET sigprocmask 0
> 1712 amd 1229033597.352781 CALL
> sigprocmask(SIG_BLOCK,0x28097c00,0xbfbfe9dc)
> 1712 amd 1229033597.352790 RET sigprocmask 0
> 1712 amd 1229033597.352801 CALL sigprocmask(SIG_SETMASK,0x28097c10,0)
> 1712 amd 1229033597.352805 RET sigprocmask 0
> 1712 amd 1229033597.352815 CALL exit(0x10)
>977 amd 1229033597.353085 RET select -1 errno 4 Interrupted
Re: preventing FIFO from EOF
> $ mkfifo /var/tmp/foo > $ buffer -i /var/tmp/foo# misc/buffer > # in another console: > $ echo hi > /var/tmp/foo > > buffer prints hi and exits. I want it to keep reading and printing > indefinitely. > > Further experimentation revealed that I need two writers: one dummy > writer that just keeps /var/tmp/foo open for writing, and the other > doing the "real work". This way buffer wouldn't exit. But how to emulate > the dummy writer? It itself needs to block on something to keep > /var/tmp/foo open. Any clean way to do this in shell? Maybe the solution > is quite simple but isn't at the tip of my tongue. > > Thanks. too easy n csh: while 1 buffer -i /var/tmp/foo end or in sh: while true; do buffer -i /var/tmp/foo done ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
preventing FIFO from EOF
$ mkfifo /var/tmp/foo $ buffer -i /var/tmp/foo# misc/buffer # in another console: $ echo hi > /var/tmp/foo buffer prints hi and exits. I want it to keep reading and printing indefinitely. Further experimentation revealed that I need two writers: one dummy writer that just keeps /var/tmp/foo open for writing, and the other doing the "real work". This way buffer wouldn't exit. But how to emulate the dummy writer? It itself needs to block on something to keep /var/tmp/foo open. Any clean way to do this in shell? Maybe the solution is quite simple but isn't at the tip of my tongue. Thanks. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Strange "changed paths" in svn commits
Hi, Is it how merging works or I'm missing something? Why /stable/7/sys and /stable/7/sys/contrib/pf are in changed paths in commit r185814? Starting from 2008 Aug they appear in almost all commits to stable/7. # svn log -v svn://svn.freebsd.org/base/stable/7 -r185814 Changed paths: M /stable/7/sys M /stable/7/sys/contrib/pf M /stable/7/sys/netinet/in_pcb.h Merge r185791 from head to stable/7: # svn diff svn://svn.freebsd.org/base/stable/7 -r185805:185814 ... diff to in_pcb.h ... Property changes on: sys/contrib/pf ___ Modified: svn:mergeinfo Merged /head/sys/contrib/pf:r185791 Property changes on: sys ___ Modified: svn:mergeinfo Merged /head/sys:r185791 # svn log -v svn://svn.freebsd.org/base/head -r185791 Changed paths: M /head/sys/netinet/in_pcb.h -- regards, Artis Caune <. CCNA | BSDA <| <' didii FreeBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: memtest86+ can not link: binutils issue?
on 31/10/2008 15:18 Andriy Gapon said the following:
>>> ld --warn-constructors --warn-common -static -T memtest_shared.lds \
>>>-o memtest_shared head.o reloc.o main.o test.o init.o lib.o
>>> patn.o screen_buffer.o config.o linuxbios.o memsize.o pci.o controller.o
>>> random.o extra.o spd.o error.o dmi.o && \
>>>ld -shared -Bsymbolic -T memtest_shared.lds -o memtest_shared
>>> head.o reloc.o main.o test.o init.o lib.o patn.o screen_buffer.o
>>> config.o linuxbios.o memsize.o pci.o controller.o random.o extra.o spd.o
>>> error.o dmi.o
>>> head.o(.text+0x7): In function `startup_32':
>>> : undefined reference to `_GLOBAL_OFFSET_TABLE_'
>>> Segmentation fault (core dumped)
Just in case anybody still remembers this issue.
It seams that the main culprit here was the following line in the linker
script:
OUTPUT_FORMAT("elf32-i386");
I was tipped just today that it should have read:
OUTPUT_FORMAT("elf32-i386-freebsd", "elf32-i386-freebsd",
"elf32-i386-freebsd");
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
