(it was directly underneath where bool.h used to be in the list, I think
I must have not been paying attention and deleted a word from the wrong
line. The machine that I was testing on still had an (old?) osfcn.h file)
Pointed out by: Andreas Klemm <andreas@klemm.gtn.com>
goes to a fair degree of trouble to enable something like this to
be safe: cd /tmp && find . -mtime +7 -delete
It removes both files and directories. It does not attempt to remove
immutable files (an earlier version I showed to a few people did a chflags
and tried to blow away even immutable files. Too risky..)
It is thought to be safe because it forces the fts(3) driven descent to
only do "minimal risk" stuff. specifically, -follow is disabled, it does
checking to see that it chdir'ed to the directory it thought it was
going to, it will *not* pass a pathname with a '/' character in it to
unlink(), so it should be totally immune to symlink tree races. If it runs
into something "fishy", it bails out rather than blunder ahead.. It's better
to do that if somebody is trying to compromise security rather than risk
giving them an opportunity. Since the unlink()/rmdir() is being called
from within the current working directory during the tree descent, there
are no fork/exec overheads or races.
As a side effect of this paranoia, you cannot do a
"find /somewhere/dir -delete", as the last argument to rmdir() is
"/somewhere/dir", and the checking won't allow it. Besides, one would use
rm -rf for that case anyway. :-)
Reviewed by: pst (some time ago, but I've removed the immutable file
deletion code that he complained about since he last saw it)
directory. Also, add gnu/usr.bin/as to the lib-tools target since libgcc
generates weak symbols, and libstdc++/libg++ use them. ie: coming from a
2.1.x system will fail without 'as'.
#include_next <string.h> wasfailing since the /usr/include directory is
first on FreeBSD, and since it was already past it, it failed some of
the tests.
The symptom was an assembler warning
"GOT relocation burb: `___EXCEPTION_TABLE__' should be global"
followed (sometimes) by a core dump. The fix makes the compiler
generate the correct GOTOFF addressing for that symbol, rather than the
GOT addressing it was emitting before.
Warning: There is still at least one serious bug in the i386 exception
code for PIC. The exception code that is generated clobbers the GOT
register (%ebx) and then tries to use it later. That leads to core
dumps at program execution time. I know where the problem is, but I do
not have a fix for it at this time. Until it is fixed, exceptions will
not work in PIC code. This is a general problem for all i386 platforms;
it is not specific to FreeBSD.
libg++'s exception code causes gcc to generate (ahem!) non-conventional
assembler code in -fpic mode that gas and ld choke on. Basically, gas
and ld require than symbols referenced in the GOT (global offset table)
are actually global (as the name implies). It attempted to work around
it before, but didn't quite go far enough to prevent a core dump in ld.
This hack causes GOT referenced symbols to be forced global. This
probably breaks the __EXCEPTION_TABLE__ stuff in pic mode, but heck, it
wasn't even possible to compile with a shared library before at all.
I'm not 100% sure what the bug is. There's two possibilities:
1: gcc/cp/exception.c has to be fixed to stop doing GOT references to
local symbols, or
2: as/ld/symorder/ld.so etc need to be taught about how to keep local
symbols around so that they can be dealt with in GOT references.
John Polstra's elfkit stuff seems to deal with this fine though, which is
why I think it's a "missing feature" in our hacked gas and ld..
kernel" mechanism. This is just the foundation - more work follows
and will be committed over the next few hours.
Submitted-by: "Eric L. Hernes" <erich@lodgenet.com> & jkh
