Re: Mixing amd64 kernel with i386 world
On Sep 28, 2013, at 12:37, Peter Jeremy pe...@rulingia.com wrote: I have a system with 4GB RAM and hence need to use an amd64 kernel to use all the RAM (I can only access 3GB RAM with an i386 kernel). OTOH, amd64 processes are significantly (50-100%) larger than equivalent i386 processes and none none of the applications I'll be running on the system need to be 64-bit. This implies that the optimal approach is an amd64 kernel with i386 userland (I'm ignoring PAE as a useable approach). I've successfully run i386 jails on amd64 systems so I know this mostly works. I also know that there are some gotchas: - kdump needs to match the kernel - anything accessing /dev/mem or /dev/kmem (which implies anything that uses libkvm) probably needs to match the kernel. Has anyone investigated this approach? I have only run i386 jails on amd64, just like you. Though for the use case you are describing, the really optimal approach would be to have real x32 support. Unfortunately, that is quite a lot of work... :) -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Can't use gcc in a clang built world
On 2013-06-27 02:02, Kevin Day wrote: Are you supposed to be able to use gcc to build userland binaries if you built world with clang? I'm on -CURRENT as of a few days ago (using armv6 but i'm not sure if that matters). Yes, the arch matters a lot. For arm, adding __clear_cache() to libgcc was explicitly disabled by Andrew here: http://svnweb.freebsd.org/base?view=revisionrevision=244382 Don't provide clear_cache or the __sync_* functions on ARM with clang as they are provided by clang as builtin functions. Maybe those functions should be in libgcc after all, if other programs depend on this. -Dimitry ___ 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: Can't use gcc in a clang built world
On Jun 27, 2013, at 20:48, Andrew Turner and...@fubar.geek.nz wrote: On Thu, 27 Jun 2013 13:06:07 +0200 Dimitry Andric dimi...@andric.com wrote: On 2013-06-27 02:02, Kevin Day wrote: Are you supposed to be able to use gcc to build userland binaries if you built world with clang? I'm on -CURRENT as of a few days ago (using armv6 but i'm not sure if that matters). Yes, the arch matters a lot. For arm, adding __clear_cache() to libgcc was explicitly disabled by Andrew here: http://svnweb.freebsd.org/base?view=revisionrevision=244382 Don't provide clear_cache or the __sync_* functions on ARM with clang as they are provided by clang as builtin functions. Maybe those functions should be in libgcc after all, if other programs depend on this. The reason to disable __clear_cache is incorrect in r244382 as it is a builtin in clang, but calls into an external copy of __clear_cache. The reason __clear_cache was disabled was because of a bug in clang where it is unable to compile a builtin function, however I only found this out recently. The issue with clang has been fixed, and, as of r251791 __clear_cache is enabled in compiler-rt. Okay, but apparently compilers such as gcc do not use compiler-rt at all, but expect the function to be available in libgcc instead. So since clang can compile the definition on arm now, shall we re-enable it for libgcc too? -Dimitry ___ 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: potential future proofing fix for aicasm build.
On May 1, 2013, at 18:44, Alfred Perlstein alf...@ixsystems.com wrote:
I took a shot at fixing this issue with building aicasm as part of
buildkernel of an older 9.0 src on a machine running HEAD.
aicasm.o: In function `__getCurrentRuneLocale': /usr/include/runetype.h:96:
undefined reference to `_ThreadRuneLocale'
I don't understand this error message... It seems like a linker error, but it
also seems to refer to an incorrect include file? Is this during linking or
compiling?
The issue seems to be two-fold:
1) Paths are not fully set to pick up the bootstrap tools needed to build.
What do you mean, exactly? In r230622 I explicitly set the PATH to
${BPATH}:${PATH}, which should be enough to pick up the bootstrap tools. This
is exactly the same path used to build the bootstrap-tools stage itself. The
kernel bootstrap tools (only aicasm, really) should be built by the host
compiler, not the cross-tools compiler.
2) include files use the host's instead of the build trees.
The first problem is fixed by changing setting of PATH from
${BPATH}:${PATH} to ${TMPPATH}.
The second is fixed by using -nostdinc and setting strict include paths using
-I directives to the compiler:
CFLAGS=-nostdinc -I${WORLDTMP}/usr/include -I.
-I${KERNSRCDIR}/dev/aic7xxx/aicasm
I don't think this is correct, as aicasm should be compiled by the host
compiler, and linked with the host libc. So if you start including headers
from the source directory, there will be a mismatch between what those headers
declare, and what is available in the host libc.
___
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: potential future proofing fix for aicasm build.
On 2013-05-02 09:47, Steven Hartland wrote: I just remembered I had an issue with aicasm when compiling our kernel that didn't have ahc or ahd on an 8.3 box. The fix was to manually delete the kernel obj directory before compiling after doing a full make buildworld. For some reason there was some cruft left in there that running make buildkernel wasn't cleaning out, could you be suffering from a similar issue? Well, a way to reproduce the problem would be nice. I tried running make buildkernel in a stable/9 tree on a 10.0 machine, and building aicasm went just fine. So it works for me... ___ 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: potential future proofing fix for aicasm build.
On 2013-05-02 11:54, Steven Hartland wrote: From: Dimitry Andric dimi...@andric.com ... Well, a way to reproduce the problem would be nice. I tried running make buildkernel in a stable/9 tree on a 10.0 machine, and building aicasm went just fine. So it works for me... I think what I did was the following:- 1. make buildkernel KERNCONF=MYCONF -j10 # failed due to aicasm And this is what I cannot reproduce. Works just fine, either with or without -j. ___ 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: potential future proofing fix for aicasm build.
On 2013-05-02 13:55, Steven Hartland wrote: From: Dimitry Andric dimi...@andric.com On 2013-05-02 11:54, Steven Hartland wrote: From: Dimitry Andric dimi...@andric.com ... I think what I did was the following:- 1. make buildkernel KERNCONF=MYCONF -j10 # failed due to aicasm And this is what I cannot reproduce. Works just fine, either with or without -j. Have just confirmed this reproduces the issue with a recent head source on 8.3-RELEASE machine. Note this is the other way around; the original poster was talking about building an older 9.0 src on a machine running HEAD. 1. rm -rf /usr/obj 2. make buildkernel KERNCONF=MYCONF -j10 # Fails with:- cc1: warnings being treated as errors aicasm_gram.c:1539: warning: no previous prototype for 'yyparse' Yes, this is because r243906 removed the prototype, since newer versions of yacc generate the prototype for yyparse themselves. Here, lex and yacc should really be (also) built as part of the kernel's bootstrap tools. Currently, they are only part of the bootstrap tools for buildworld, which explains the events below. 3. make buildworld So here the correct versions of lex and yacc are built... 4. make buildkernel KERNCONF=MYCONF -j10 # Still fails with:- cc1: warnings being treated as errors aicasm_gram.c:1539: warning: no previous prototype for 'yyparse' However, since the .c file is newer than the .y file, it does not get regenerated... Fix is: 1. rm -rf /usr/obj/usr/src/sys/MYCONF 2. make buildkernel KERNCONF=MYCONF -j10 # Now works And with this, you have forced regeneration of the aicasm_gram.c file, so now it builds correctly. E.g., I think you might get away with just rm'ing all the generated aicasm*.c files. ___ 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: Rebooting from loader causes a fault in VMware Workstation
On Apr 22, 2013, at 17:29, John Baldwin j...@freebsd.org wrote: On Saturday, April 20, 2013 7:51:06 am Joshua Isom wrote: On 4/19/2013 8:48 PM, Jeremy Chadwick wrote: I'm happy to open up a ticket with VMware about the issue as I'm a customer, but I find it a little odd that other operating systems do not exhibit this problem, including another BSD. Ones which reboot just fine from their bootloaders: - Linux -- so many that I don't know where to begin: ArchLinux 2012.10.06, CentOS 6.3, Debian 6.0.7, Finnix 1.0.5, Knoppix 7.0.4, Slackware 14.0, and Ubuntu 11.10 - OpenBSD 5.2 - OpenIndiana -- build 151a7 (server version) So when you say Blame VMware, I'd be happy to, except there must be something FreeBSD's bootstraps are doing differently than everyone else that causes this oddity. Would you not agree? A triple fault is standard practice as a fail safe guarantee of reboot. It's used either as a reboot, switch to real mode(IBM OS/2), or catastrophic unrecoverable failure. By the looks of grub(Linux and Solaris), it either jumps to it's own instruction, hoping the bios catches it(tell the BIOS a boot failure, which may result in no effect), or jumps to a location that I can't yet determine what code exists there. I can't seem to find OpenBSD's reboot method from OpenBSD's cvsweb, only an exit but not where that exit leads to. The native operating system is irrelevant, only the boot loader so all the Linux distributions and Solaris forks all count as grub. Many other bootloaders don't even have the reboot option, just fail. Here's barebox, a Das U-Boot fork: /** How to reset the machine? */ while(1) In any case, it's a bag of tricks, finding something that works and is nice. We're talking 30 years of legacy. A triple fault, assuming the mbr and loader ignores or zeroes previous memory, is guaranteed and doesn't hang. Actually, the traditional reboot method in real-mode (e.g. in DOS) is to jump to 0x:0. The BIOS is supposed to have a restart routine at that location. I've also seen jumps to 0xf000:fff0. For example, BTX (the mini-kernel that hosts the loader and boot2) uses the latter: /* * Reboot or await reset. */ sti # Enable interrupts testb $0x1,btx_hdr+0x7 # Reboot? exit.3: jz exit.3 # No movw $0x1234, BDA_BOOT # Do a warm boot ljmp $0xf000,$0xfff0# reboot the machine I have tried to ascertain it actually arrives at this code when rebooting from the loader, but it does not seem to ever make it there, at least not to the jump to f000:fff0. Maybe VMware intercepts the switching back to real mode in the previous part, and dies on that, I am not sure. It is of course rather tricky to print off any debug messages at that point. :-) ___ 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: Rebooting from loader causes a fault in VMware Workstation
On Apr 23, 2013, at 23:46, Andriy Gapon a...@freebsd.org wrote: on 23/04/2013 19:31 John Baldwin said the following: On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote: ... 0x90e8: lgdtl 0x95d0 0x90ef: ljmpw $0x18,$0x90f5 Triple fault CPU Reset (CPU 0) ESI=0004503c EDI=3fe50968 EBP=00094a80 ESP=1800 EIP=90ef EFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0033 a000 00cff300 DPL=3 DS [-WA] CS =0008 00cf9a00 DPL=0 CS32 [-R-] SS =0010 00cf9300 DPL=0 DS [-WA] DS =0033 a000 00cff300 DPL=3 DS [-WA] FS =0033 a000 00cff300 DPL=3 DS [-WA] GS =0033 a000 00cff300 DPL=3 DS [-WA] LDT= 8200 DPL=0 LDT TR =0038 5f98 2067 8900 DPL=0 TSS32-avl GDT= ff85c789 This seems wrong (address is way too high). I wonder if the gdtdesc was trashed by something? Can you dump memory before the lgdtl instruction at the 0x95d0 address? Looks correct: Breakpoint 1, 0x90e8 in ?? () (gdb) x/i $eip 0x90e8: lgdtl 0x95d0 (gdb) x/3xh 0x95d0 0x95d0: 0x003f 0x9590 0x (gdb) x/16xh 0x9590 0x9590: 0x 0x 0x 0x 0x 0x 0x9a00 0x00cf 0x95a0: 0x 0x 0x9300 0x00cf 0x 0x 0x9a00 0x Nevertheless doing stepi leads to exactly the same triple fault. Is it because lgdt loads the GDT from the ds segment, and ds is now 33, not 0 (or equal to CS, I'm not sure which is correct here)? ___ 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: Rebooting from loader causes a fault in VMware Workstation
On Apr 24, 2013, at 00:03, Dimitry Andric d...@freebsd.org wrote: On Apr 23, 2013, at 23:46, Andriy Gapon a...@freebsd.org wrote: on 23/04/2013 19:31 John Baldwin said the following: On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote: ... 0x90e8: lgdtl 0x95d0 0x90ef: ljmpw $0x18,$0x90f5 Triple fault CPU Reset (CPU 0) ESI=0004503c EDI=3fe50968 EBP=00094a80 ESP=1800 EIP=90ef EFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0033 a000 00cff300 DPL=3 DS [-WA] CS =0008 00cf9a00 DPL=0 CS32 [-R-] SS =0010 00cf9300 DPL=0 DS [-WA] DS =0033 a000 00cff300 DPL=3 DS [-WA] FS =0033 a000 00cff300 DPL=3 DS [-WA] GS =0033 a000 00cff300 DPL=3 DS [-WA] LDT= 8200 DPL=0 LDT TR =0038 5f98 2067 8900 DPL=0 TSS32-avl GDT= ff85c789 This seems wrong (address is way too high). I wonder if the gdtdesc was trashed by something? Can you dump memory before the lgdtl instruction at the 0x95d0 address? Looks correct: Breakpoint 1, 0x90e8 in ?? () (gdb) x/i $eip 0x90e8: lgdtl 0x95d0 (gdb) x/3xh 0x95d0 0x95d0: 0x003f 0x9590 0x (gdb) x/16xh 0x9590 0x9590: 0x 0x 0x 0x 0x 0x 0x9a00 0x00cf 0x95a0: 0x 0x 0x9300 0x00cf 0x 0x 0x9a00 0x Nevertheless doing stepi leads to exactly the same triple fault. Is it because lgdt loads the GDT from the ds segment, and ds is now 33, not 0 (or equal to CS, I'm not sure which is correct here)? Indeed, the DS segment was incorrect, the GDT should be loaded from the CS segment instead. This diff fixes the issue for me (and now reboot command from loader nicely reboots in VMware): Index: sys/boot/i386/btx/btx/btx.S === --- sys/boot/i386/btx/btx/btx.S (revision 248910) +++ sys/boot/i386/btx/btx/btx.S (working copy) @@ -248,7 +248,7 @@ exit: cli # Disable interrupts /* * Restore the GDT in case we caught a kernel trap. */ - lgdt gdtdesc# Set GDT + lgdt %cs:gdtdesc# Set GDT /* * To 16 bits. */ ___ 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: WORLDTMP on a ram disk
On Apr 20, 2013, at 11:55, Kimmo Paasiala kpaas...@gmail.com wrote: Poking around the /usr/src/Makefile.inc1 I see that there's a variable called WORLDTMP that seems to set the location for temporary files during the world build. My question is now: Is it safe to put WORLDTMP on a ram disk, for example tmpfs(5)? Looking at the build process it seems to me that the temporary files are no longer needed after make buildworld has finished? The problem is that you need those temporary files for installworld, and you must reboot with your new kernel before running 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: clang: -mno-omit-leaf-frame-pointer
On Mar 30, 2013, at 09:10, Andriy Gapon a...@freebsd.org wrote: It seems that, unlike gcc, for clang -fno-omit-frame-pointer does not imply -mno-omit-leaf-frame-pointer. This is probably a bug. Yes, this is indeed the case. There is even a rather old unresolved PR for it in LLVM's Bugzilla: http://llvm.org/bugs/show_bug.cgi?id=9825 Meanwhile I would like to propose the following amd64-specific patch. Perhaps the same type of change would be useful for powerpc as well. Most likely yes. I would like this change primarily for DTrace (fbt), but other debugging/profiling code may benefit from it as well. I chose to make -mno-omit-leaf-frame-pointer not conditional on clang, because with gcc it is just a nop (i.e. it doesn't hurt anything). The patch looks good to me, please commit. ___ 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: clang - odd macro / conditional expansion behaviour?
On Mar 12, 2013, at 04:17 , Adrian Chadd adr...@freebsd.org wrote: In file included from /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ath/../../contrib/sys/dev/ath/ath_hal/ar9300/ar9300_eeprom.c:21: /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ath/../../contrib/sys/dev/ath/ath_hal/ar9300/ar9300template_generic.h:107:3: error: implicit conversion from 'int' to 'u_int8_t' (aka 'unsigned char') changes value from -477 to 35 [-Werror,-Wconstant-conversion] FREQ2FBIN(2412, 1), ^~ /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ath/../../contrib/sys/dev/ath/ath_hal/ar9300/ar9300eep.h:136:65: note: expanded from macro 'FREQ2FBIN' (((y) == HAL_FREQ_BAND_2GHZ) ? ((x) - 2300) : (((x) - 4800) / 5)) ~^~~ I cannot find the exact code you are referencing here, but I assume it is some sort of global initialization? If so, this is most likely http://llvm.org/bugs/show_bug.cgi?id=10030, which has been languishing in LLVM's Bugzilla for a way too long time. :-( ___ 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: clang generated code sometimes confuses fbt
On 2013-03-05 13:02, Andriy Gapon wrote: on 04/03/2013 13:50 Dimitry Andric said the following: Actually, that way of fixing breaks it for gcc, so it should really be fixed in sort_iidescs() instead. See attached diff; I verified it works for both gcc-compiled and clang-compiled objects. Impossible! It looks like the attached diff was a nop change :-) BTW, so changing clang to match gcc is not an option? I do not insist, just curious. I could not find a good argument to present to upstream to change this behaviour, except gcc has been doing it for x years, without a good reason. :-) And I did not want to make yet another FreeBSD specific change. In my opinion, gcc is losing information here, e.g. the original pathname to the source file. There is no reason debugging tools cannot be fixed to be able to cope with this. ___ 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: clang generated code sometimes confuses fbt
On 2013-03-04 08:57, Matt Burke wrote: On 03/02/13 17:35, Andriy Gapon wrote: To summarize: I would be glad of either clang generated code was fbt-friendly or if ctf information was generated for bpobj_iterate_impl. Either is perfect for me. Apologies if this is a silly suggestion, but are you building with -O0? I've noticed backtraces being hard to follow (i.e. skipping intermediate and wrapper functions) with a kernel built with the default optimisation level, and it seems to me that the same thing may be happening here - the wrappers are being optimised out. No, the wrappers (bpobj_iterate and bpobj_iterate_nofree) are externally visible functions, so they cannot be optimized out. Both of them call bpobj_iterate_impl, which is a static function, e.g. a candidate for automatic inlining. However, bpobj_iterate_impl is quite big, and called from 3 different locations, so it does not actually get inlined, even with -O2. ___ 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: clang generated code sometimes confuses fbt
On 2013-03-03 21:02, Dimitry Andric wrote:
On 2013-03-03 17:36, Andriy Gapon wrote:
on 03/03/2013 17:45 Dimitry Andric said the following:
...
So to fix this inconsistency, we could either change dw_read() to use
the full name instead of the basename, or change sort_iidescs() to use
the basename instead of the full name.
The only upstream I have been able to find, Illumos, had the same code
as FreeBSD for both of these functions, so it is likely they never
noticed it before...
My preference would be to remove the basename() call from dw_read(), as
in the attached diff. That seems to fix the problem here; the diff of
ctfdump output before and after becomes:
Actually, that way of fixing breaks it for gcc, so it should really be
fixed in sort_iidescs() instead. See attached diff; I verified it works
for both gcc-compiled and clang-compiled objects.
Index: cddl/contrib/opensolaris/tools/ctf/cvt/output.c
===
--- cddl/contrib/opensolaris/tools/ctf/cvt/output.c (revision 247448)
+++ cddl/contrib/opensolaris/tools/ctf/cvt/output.c (working copy)
@@ -363,6 +363,7 @@ sort_iidescs(Elf *elf, const char *file, tdata_t *
for (i = 0; i nent; i++) {
GElf_Sym sym;
+ char *bname;
iidesc_t **tolist;
GElf_Sym ssym;
iidesc_match_t smatch;
@@ -377,6 +378,8 @@ sort_iidescs(Elf *elf, const char *file, tdata_t *
switch (GELF_ST_TYPE(sym.st_info)) {
case STT_FILE:
+ bname = strrchr(match.iim_name, '/');
+ bname = bname == NULL ? match.iim_name : bname + 1;
match.iim_file = match.iim_name;
continue;
case STT_OBJECT:
___
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: clang generated code sometimes confuses fbt
On 2013-03-02 21:23, Dimitry Andric wrote: On 2013-03-02 18:52, Andriy Gapon wrote: on 02/03/2013 19:35 Andriy Gapon said the following: Now, I am not quite sure why ctfconvert skips bpobj_iterate_impl in the clang-generated code. Seems like some sort of a bug in ctfconvert. It seems that gcc and clang put different names for symbol of type FILE: clang: readelf -a -W /usr/obj/usr/src/sys/TRANT/bpobj.o| fgrep -w FILE 1: 0 FILELOCAL DEFAULT ABS /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/bpobj.c gcc: readelf -a -W /usr/obj/usr/src/sys/ODYSSEY/bpobj.o| fgrep -w FILE 1: 0 FILELOCAL DEFAULT ABS bpobj.c ctfconvert seems to compare this value with bpobj.c and so in the clang case it doesn't recognize the static symbols. Does my analysis seem reasonable? Have you verified that ctfconvert does the right thing, if you modify the FILE symbol to have just the filename? Debug log of ctfconvert operating on a gcc-compiled bpobj.o: http://www.andric.com/freebsd/ctfconvert-bpobj-gcc.log The same, but on a clang-compiled bpobj.o: http://www.andric.com/freebsd/ctfconvert-bpobj-clang.log This latter log does not change at all, if you change the FILE symbol to just bpobj.c. So there seems to something else in (probably) the debug information that confuses ctfconvert. ___ 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: clang generated code sometimes confuses fbt
On 2013-03-03 17:36, Andriy Gapon wrote:
on 03/03/2013 17:45 Dimitry Andric said the following:
Debug log of ctfconvert operating on a gcc-compiled bpobj.o:
http://www.andric.com/freebsd/ctfconvert-bpobj-gcc.log
The same, but on a clang-compiled bpobj.o:
http://www.andric.com/freebsd/ctfconvert-bpobj-clang.log
This latter log does not change at all, if you change the FILE symbol to
just bpobj.c. So there seems to something else in (probably) the
debug information that confuses ctfconvert.
Sorry, but these two logs look so different to each other and your clang log is
so different from a log that I get here with that I believe that something is
wrong in your test.
Indeed, apparently I copy/pasted the wrong command line from earlier in
the build log, where it does not use -g (it is probably for the userland
version of ctf).
When I used the command line for the kernel build of bpobj.c, it did
have -g, and the ctfconvert log had a lot more information. I have
re-uploaded the logfile on the second URL above.
I also had a look at ctfconvert, and it appears that in its dwarf
reader, in cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c, it uses the
basename, see lines 1825 through 1827:
1762 int
1763 dw_read(tdata_t *td, Elf *elf, char *filename __unused)
1764 {
[...]
1824 if ((dw.dw_cuname = die_name(dw, cu)) != NULL) {
1825 char *base = xstrdup(basename(dw.dw_cuname));
1826 free(dw.dw_cuname);
1827 dw.dw_cuname = base;
1828
1829 debug(1, CU name: %s\n, dw.dw_cuname);
1830 }
while later on, in actually outputting the processed symbol table, in
cddl/contrib/opensolaris/tools/ctf/cvt/output.c, it does not take the
basename, but the full name:
336 static iiburst_t *
337 sort_iidescs(Elf *elf, const char *file, tdata_t *td, int fuzzymatch,
338 int dynsym)
339 {
[...]
364 for (i = 0; i nent; i++) {
365 GElf_Sym sym;
[...]
372 if (gelf_getsym(data, i, sym) == NULL)
373 elfterminate(file, Couldn't read symbol %d,
i);
374
375 match.iim_name = (char *)strdata-d_buf + sym.st_name;
376 match.iim_bind = GELF_ST_BIND(sym.st_info);
377
378 switch (GELF_ST_TYPE(sym.st_info)) {
379 case STT_FILE:
380 match.iim_file = match.iim_name;
381 continue;
[...]
397 iidesc = find_iidesc(td, match);
398
399 if (iidesc != NULL) {
400 tolist[*curr] = iidesc;
401 iidesc-ii_flags |= IIDESC_F_USED;
402 (*curr)++;
403 continue;
404 }
On line 375, the full name is gotten from the elf symbol, on line 379 it
is assigned to the iidesc_match_t struct which is used for searching,
and in line 397 it does the actual search.
So to fix this inconsistency, we could either change dw_read() to use
the full name instead of the basename, or change sort_iidescs() to use
the basename instead of the full name.
The only upstream I have been able to find, Illumos, had the same code
as FreeBSD for both of these functions, so it is likely they never
noticed it before...
My preference would be to remove the basename() call from dw_read(), as
in the attached diff. That seems to fix the problem here; the diff of
ctfdump output before and after becomes:
--- ctfdump-before.log 2013-03-03 20:37:30.0 +0100
+++ ctfdump-after.log 2013-03-03 20:37:47.0 +0100
@@ -9,8 +9,8 @@
cth_lbloff = 0
cth_objtoff = 8
cth_funcoff = 10
- cth_typeoff = 140
- cth_stroff = 24164
+ cth_typeoff = 160
+ cth_stroff = 24184
cth_strlen = 20066
- Label Table
@@ -23,6 +23,8 @@
- Functions --
+ [0] FUNC (bpobj_iterate_impl) returns: 3 args: (1089, 1136, 56, 1092, 1163)
+ [1] FUNC (space_range_cb) returns: 3 args: (56, 1124, 1092)
[2] FUNC (bpobj_alloc) returns: 324 args: (1080, 1092, 3)
[3] FUNC (bpobj_alloc_empty) returns: 324 args: (1080, 3, 1092)
[4] FUNC (bpobj_close) returns: 55 args: (1089)
@@ -5099,10 +5101,10 @@
total number of data objects= 1
- total number of functions = 12
- total number of function arguments = 39
+ total number of functions = 14
+ total number of function arguments = 47
maximum argument list length= 6
- average argument list length= 3.25
+ average argument list length= 3.36
total number of types = 1173
total number of integers= 18
Index: cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c
Re: clang generated code sometimes confuses fbt
On 2013-03-02 18:52, Andriy Gapon wrote:
on 02/03/2013 19:35 Andriy Gapon said the following:
Now, I am not quite sure why ctfconvert skips bpobj_iterate_impl in the
clang-generated code. Seems like some sort of a bug in ctfconvert.
It seems that gcc and clang put different names for symbol of type FILE:
clang:
readelf -a -W /usr/obj/usr/src/sys/TRANT/bpobj.o| fgrep -w FILE
1: 0 FILELOCAL DEFAULT ABS
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/bpobj.c
gcc:
readelf -a -W /usr/obj/usr/src/sys/ODYSSEY/bpobj.o| fgrep -w FILE
1: 0 FILELOCAL DEFAULT ABS bpobj.c
ctfconvert seems to compare this value with bpobj.c and so in the clang case
it doesn't recognize the static symbols.
Does my analysis seem reasonable?
Have you verified that ctfconvert does the right thing, if you modify
the FILE symbol to have just the filename?
Indeed, clang puts the original filename from the command line in the
.file directive, while gcc explicitly removes any directory names; see
contrib/gcc/toplev.c, around line 680:
void
output_file_directive (FILE *asm_file, const char *input_name)
{
int len;
const char *na;
if (input_name == NULL)
input_name = stdin;
len = strlen (input_name);
na = input_name + len;
/* NA gets INPUT_NAME sans directory names. */
while (na input_name)
{
if (IS_DIR_SEPARATOR (na[-1]))
break;
na--;
}
...
That NA gets INPUT_NAME sans directory names comment was inserted by
rms in r279. :-) So I guess this is the way gcc has done it from the
start, but there is no explanation as to why rms chose to remove those
directory names. I do not see the problem, except maybe for having
reproducible builds?
-Dimitry
___
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: SIGSEGV/SIGBUS when accessing after end of mmapped file; why it differs with GCC?
On 2013-02-14 15:04, nat...@centrum.cz wrote: Od: Konstantin Belousov kostik...@gmail.com On Wed, Feb 13, 2013 at 12:13:58PM -0500, Ryan Stone wrote: On Wed, Feb 13, 2013 at 11:18 AM, nat...@centrum.cz wrote: ... Machine in question runs amd64 FreeBSD 9.1-RC2, but this has also ... You did not specified anything about version of the FreeBSD used, nor the exact compiler invocations. Using the crystal ball, I see the r244600 for HEAD and r244904 for stable/9, if you use --gc-sections flags. This is more or less consistent with what you reported, since gcc from ports uses binutils from ports, which have newer ld with bugfix already applied. ... In my case it is indeed so that while the gcc42 generated binary does not contain the note, gcc47 binary does contain it. I am indeed using --gc-sections linker option, however whether this, potentially with some bug in linker, caused the note to be missing, I am not sure, as I did not investigate into this. The solution of the original problem is thus to ensure that the note presence is consistent and that the correct signal is handled. As Kostik already pointed out, FreeBSD's ld contains a bug which erroneously strips out the note sections, if you use --gc-sections. I fixed that for head in r244600, and merged it to stable/9 in r244904. Since you said you are running FreeBSD 9.1-RC2, you will not have this particular fix, so it is the most likely cause for your problems. The reason you do not see it with gcc 4.7 is that it will use a much newer ld from the binutils port, where this issue with --gc-sections was fixed a long time ago. ___ 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: Turn on CLANG_IS_CC when not building gcc
On 2013-02-13 12:48, Dag-Erling Smørgrav wrote: The following patches (for
head and stable/9) automatically enable
CLANG_IS_CC if GCC is disabled but CLANG is not. Any objections?
This looks fine to me. Otherwise, if ${CC} isn't set to clang,
buildworld might fail in mysterious ways... :)
___
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: Eliminating a warning in sys/boot
On 2013-02-10 01:10, Sean Bruno wrote: So, this is not a valid warning in our universe and I'd like to silence it when compiling sys/boot as printf(9) and sprintf(9) supports this format. How can we silence this warning for the FreeBSD universe? === efi/libefi (all) In file included from efinet.c:39: /home/sbruno/fbsd_head/sys/boot/efi/libefi/../../common/dev_net.c:328:19: warning: invalid conversion specifier 'D' [-Wformat-invalid-specifier] sprintf(temp, %6D, d-myea, :); Either eliminate the non-standard printf format specifier, or use the -fformat-extensions flag while compiling. ___ 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: base gcc and _GLIBCXX_USE_C99
On 2013-02-01 14:01, Andriy Gapon wrote: on 28/01/2013 17:11 Andriy Gapon said the following: I wonder why the following is the case for the base gcc. /usr/include/c++/4.2/bits/c++config.h: /* Define if C99 functions or macros from wchar.h, math.h, complex.h, stdio.h, and stdlib.h can be used or exposed. */ /* #undef _GLIBCXX_USE_C99 */ Because of this undef there is no e.g. std::strtoll(). Ditto for other things in stdlib.h. Maybe this support can't be enabled, because we don't expose all the required functions yet? Or maybe it is just something that was committed years ago, and then forgotten. If we are sure that all the C99 functions libstdc++ requires are now available and working, I see no problem in turning on _GLIBCXX_USE_C99. ___ 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: use after free in grep?
On 2012-12-20 08:13, Eitan Adler wrote:
in xrealloc_impl
338 new_ptr = realloc(ptr, new_size);
339 if (new_ptr != NULL)
340 {
341 hash_table_del(xmalloc_table, ptr);
^^^ isn't this a use-after-free of ptr?
Yes, realloc does not guarantee the realloc'd space will be at the same
address, so it may free ptr at its discretion. Also, there is a memory
leak if realloc() returns NULL. This is a very usual mistake when using
realloc(). :-)
Probably, the code should do the hash_table_del() before the realloc(),
but I am not sure if hash_table_del() will already free ptr.
___
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: clang mangling some static struct names?
On 2012-11-16 23:04, Navdeep Parhar wrote:
On 11/16/12 13:49, Roman Divacky wrote:
Yes, it does that. iirc so that you can have things like
void foo(int cond) {
if (cond) {
static int i = 7;
} else {
static int i = 8;
}
}
working correctly.
It's not appending the .n everywhere. And when it does, I don't see any
potential collision that it prevented by doing so. Instead, it looks
like the .n symbol corresponds to the nth element in the structure (so
this is not name mangling in the true sense). I just don't see the
point in doing things this way. It is only making things harder for
debuggers.
I don't think the point is making things harder for debuggers, the point
is optimization. Since static variables and functions can be optimized
away, or arbitrarily moved around, you cannot count on those symbols
being there at all.
___
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: opensolaris B_TRUE and B_FALSE
On 2012-10-29 09:12, Erik Cederstrand wrote:
Den 29/10/2012 kl. 00.24 skrev Ian Lepore free...@damnhippie.dyndns.org:
Look further up in sys/cddl/compat/opensolaris/sys/types.h, they're also
defined (as macros rather than enum) in the KERNEL case. They're also
defined (as enum) in sys/gnu/fs/xfs/xfs_types.h. (Once again, SlickEdit
pays for itself by answering with one right-click a question that would
have been a pain to use grep for.)
The code in the report is /sbin/zpool, so I assume it's not KERNEL code. As I
wrote in my email, I can see B_TRUE and B_FALSE are defined as boolean_t in
sys/cddl/compat/opensolaris/sys/types.h But I can't see that boolean_t is
defined anywhere in the included headers as long as KERNEL is not defined.
In sys/cddl/compat/opensolaris/sys/types.h, there is:
typedef enum { B_FALSE, B_TRUE }boolean_t;
This line defines the boolean_t type. Maybe the type itself is never
used, but only the enum values. Sort of like a an anonymous enum in C++.
___
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: Clang '-g' unused warnings in FreeBSD (linking)
On 2012-07-15 15:39, Jakub Lach wrote: While this is old bug upstream: http://llvm.org/bugs/show_bug.cgi?id=8611 http://llvm.org/bugs/show_bug.cgi?id=8630 Here, (FreeBSD clang version 3.1 (branches/release_31 156863) 20120523 Target: x86_64-unknown-freebsd9.0) Passing -g during linking (which lot's of projects do by including CFLAGS in linking) I still get clang: warning: argument unused during compilation: '-g' ... On 2012-07-15 16:04, Jakub Lach wrote: Maybe I should include a question too, so I have better chance of getting answer :) Is this intended behaviour? This is a bit typical issue for clang, which originates in the way it parses command line arguments: different parts of the compiler stages 'claim' arguments, and any that are left at the end are reported as unused. Regarding the LLVM PRs you mentioned, one could argue that passing '-g' to the link stage is nonsensical, since ld cannot add debug information, it can only remove it (via the '-s' flag). But since it is apparently common to do this, it may be a bit too annoying to complain about it. In any case, upstream fixed it for Linux, but not for any other operating system. I will make a similar fix for FreeBSD, and send it upstream 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: Pull in upstream before 9.1 code freeze?
On 2012-07-05 12:03, Olivier Smedts wrote: ... You mean, this desktop dumb mode thing that makes my hard drive led crazy-blink and makes me hit (first) my desk and (then) ^C before anything is displayed ? The next step will be to start searching the internet in the background, while you incrementally type characters... (complete with insulting Did you mean 'foo'? type suggestions. ;) ___ 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: [CFC/CFT] large changes in the loader(8) code
On 2012-06-26 14:50, Andrey V. Elsukov wrote: Some time ago i have started reading the code in the sys/boot. Especially i'm interested in the partition tables handling. I found several problems: 1. There are several copies of the same code in the libi386/biosdisk.c and common/disk.c, and partially libpc98/biosdisk.c. 2. ZFS probing is very slow, because the ZFS code doesn't know how many disks and partitions the system has: http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 3. The GPT support doesn't check CRC and even doesn't know anything about the secondary GPT header/table. So, i have created the branch and committed the changes: http://svnweb.freebsd.org/base/user/ae/bootcode/ The patch is here: http://people.freebsd.org/~ae/boot.diff FWIW, I verified it compiles OK with clang, and especially boot2's size isn't increased at all. It would be nice if you could check it with clang now and again, before you finally merge this project into head. ___ 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: Something wrong with curs_threads(3X) ?
On 2012-05-21 18:41, Yanhui Shen wrote: In curs_threads(3X), at the beginning of the manual: typedef int (*NCURSES_WINDOW_CB)(WINDOW *, void *); typedef int (*NCURSES_SCREEN_CB)(SCREEN *, void *); int set_escdelay(int size); int set_tabsize(int size); int use_screen(SCREEN *scr, NCURSES_WINDOW_CB func, void *data); int use_window(WINDOW *win, NCURSES_SCREEN_CB func, void *data); That's indeed a documentation error. Fixed in r235773, 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
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On 2011-12-10 02:21, Gleb Kurtsou wrote: Please find test case and test results attached. (gcc-test1.shar.txt) The long story short: only gcc-4.2 is affected, gcc 3.4, 4.4 and 4.6 are ok. clang is ok. (test-cc.txt) Nearly all of the workarounds I used in original test doesn't work in this test case (see #ifdef BAD_FIX in sources). gcc 4.2 fails even with -O1, it has nothing to do with -fno-omit-frame-pointer, finline-functions, etc. (test-cflags.txt) Compile with -DFIX1 to work around problem (replace struct assignment with memcpy): % make test XFLAGS=-O2 -DFIX1 rm -f gcc-test1 src1.o src2.o src3.o cc -O2 -DFIX1 -g -std=gnu99 -c src1.c cc -O2 -DFIX1 -g -std=gnu99 -c src2.c cc -O2 -DFIX1 -g -std=gnu99 -c src3.c cc -O2 -DFIX1 -g -std=gnu99-o gcc-test1 src1.o src2.o src3.o /home/gleb/projects/gcc-test1/gcc-test1 ok Happy hacking! Hi Gleb, I did some bisecting, and I found the exact gcc trunk revision that fixes this bug: http://gcc.gnu.org/viewcvs?view=revisionrevision=119760 So far the good news, now the bad news: this revision is actually a merge from gcc's mem-ssa branch! The full diff is almost 10,000 lines... Also, although it's still under GPLv2, the diff doesn't apply cleanly to our version. :( ___ 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: proper newfs options for SSD disk
On 2012-05-18 22:11, User Wojtek wrote: what are proper settings a) 4kB fragments so everything is 4k aligned? SSD drives itself reports as 512 byte blocks, but it is recomenned constantly on many places about 4K alignment for SSD. That 4k alignment is most likely meant for so-called advanced format hard drives (the good old magnetic platter ones); these present 512 byte sectors to the ATA interface, but use 4096 byte sectors internally. With SSDs however, you cannot automatically tell what their erase block size is. Some of them use 128kB, others 256kB, and there are probably also devices with variable erase block sizes. You may be able to find the exact erase block size in the technical documentation of your specific SSD. But the manufacturers don't always tell. :) b) small fragments (like 1KB) to reduce space usage, as there is no seeking so it will not slow down but save space on relatively small SSD I don't think you would want to write lots of very small fragments to any SSD. :) c) anything else? Be sure to use -t enable when creating the filesystem: -t enable | disable Turn on/off the TRIM enable flag. If enabled, and if the under- lying device supports the BIO_DELETE command, the file system will send a delete request to the underlying device for each freed block. The trim enable flag is typically set when the underlying device uses flash-memory as the device can use the delete command to pre-zero or at least avoid copying blocks that have been deleted. ___ 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: De-warning...ing clang Kernel Builds
On 2012-03-08 19:16, Brandon Falk wrote: Is there anyone actively working on cleaning up the codebase to not throw warnings when built with clang. I realize these warnings do not matter, but I generally prefer to get rid of warnings if possible. I can't imagine it would take too long, although I could see an issue with developers not familiar with the clang warning system forgetting to check clang builds for warnings while they add new code. Take care saying these warnings do not matter. Unfortunately, it is not as simple as that. In some cases, the warnings are indeed superfluous, and it is rather annoying to fix them (a.k.a shut up the compiler). In other cases, however, the warnings point out real problems. Obviously, those problems can be fixed, but sometimes that is either very hard, or very disruptive, or both. And there are even cases where the problem may be very subtle, and cannot be fixed without extremely careful inspection (and retrospection). Last but not least, applying fixes may break code in unexpected ways. Especially if the code has been sitting untouched for years, it is prone to be sensitive to even the smallest changes... One big issue is that there are no tinderbox builds that use clang, and therefore people don't notice that commits introduce new warnings (or errors, even) when building with clang. This is something that should be fixed sooner rather than later. On the other hand, if -CURRENT would be switched to use clang by default, the problems would hopefully be taken care of sooner. :) ___ 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: [clang] Build error on r232474 (and a few before, don't know exactly which)
On 2012-03-04 00:52, Brandon Falk wrote: ... I was trying to navigate the log in `edit`. Now that I'm in vim I quickly found the error. lint: cannot exec /usr/obj/root/src/tmp/usr/bin/cc: No such file or directory *** [llib-lposix.ln] Error code 1 Huh, that's weird. I see no reason that it wouldn't install cc during the cross-tools stage, unless you have WITHOUT_GCC in your src.conf (and aren't using WITH_CLANG_IS_CC at the same time). Can you post your src.conf file, please? ___ 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: Parallels v4 regression (aka ada(4) oddity) in RELENG_9
On 2012-01-23 19:46, Ed Maste wrote: ... Do you have the reproduction steps documented somewhere (and if not, can you write them up)? In order to have working automated installs we need to be able to unconditionally reinit a drive w/o having behavoiur depend on what happens to be left behind. Maybe just zero the first and last N sectors of the drive, where N is 10,000 or greater? ___ 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: building on FreeBSD 7.3 with Clang
On 2012-01-09 20:38, Lenny Maiorani wrote: Hi. I am trying to build a userspace application on FreeBSD 7.3 with Clang. I have come across 2 problems so far and I am looking for any tips or guidance the community has. My problems are both related to binutils so far: 1. Missing symbols : http://llvm.org/bugs/show_bug.cgi?id=9758 2. crtendS.o problem : http://sourceware.org/bugzilla/show_bug.cgi?id=12887 At this point I need to rebuild my toolchain to get a new crtendS.o. Are there other pitfalls I need to be aware of? It's probably easiest to install the binutils port, and use that for building clang and your application. Otherwise, you can manually apply the patches mentioned in LLVM PR 9758 to your system binutils, and recompile them. ___ 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: Subversion upgrades of existing dirs
On 2011-12-22 18:33, Sean Bruno wrote: How do I upgrade an existing svn tree with the current svn client. I don't really get what the client is trying to tell me here. [sbruno@ref9-xen32 /dumpster/scratch/sbruno-scratch/9]$ svn up svn: E155036: Please see the 'svn upgrade' command svn: E155036: Working copy '/dumpster/scratch/sbruno-scratch/9' is an old development version (format 12); to upgrade it, use a format 18 client, then use 'tools/dev/wc-ng/bumpt [sbruno@ref9-xen32 /dumpster/scratch/sbruno-scratch/9]$ svn upgrade . svn: E155019: Can't upgrade '/dumpster/scratch/sbruno-scratch/9' as it is not a pre-1.7 working copy directory svn: E15: Missing default entry This is on an NFS share, right? That is most likely fixed by running NFSv4, or by making sure rpc.lockd and rpc.statd run on both server and client. It looks like Subversion needs file locking to work in a certain way, otherwise it will give these obscure messages. Maybe it is useful to report it to the Subversion guys... (and hopefully not get the answer don't do that back :) ___ 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: 64bit build errors
On 2011-12-07 01:40, Da Rock wrote: I'm trying to build some newer versions of ffserver. But I keep getting asm build errors when I get to libavcodec/vp*. Error: `(%esi,%eax)' is not a valid 64 bit base/index expression If I set it to build static it fails at h264. Error: `-1(%edi)' is not a valid 64 bit base/index expression Googling hasn't proved helpful in finding an answer. I've tried setting some configure options: arch=amd64/x86_64, disabling cmov/fast_cmov, ebx, etc. Any ideas how to fix this? At first glance, I'd say you are compiling it with a 32-bit compiler or assembler. In any case, I downloaded the latest version (0.8.7) from ffmpeg.org, and it compiles just fine with base gcc. What are the exact commands you are running? ___ 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: .eh_frame, .eh_frame_hdr - how to remove that trash
On 2011-10-20 12:44, Wojciech Puchar wrote: i both don't use C++ and don't want to debug when i am linking final binary. how to turn this off? objcopy --remove-section .eh_frame_hdr --remove-section .eh_frame --remove-section .rel.eh_frame --remove-section .rela.eh_frame $your_executable No warranty for any blown-off extremities, though. ___ 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: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586
On 2011-07-21 14:17, Julian H. Stacey wrote: Summary: I found a problem with CFLAGS += -march=i586 on an i686 linking a crt.o for an i686, then not running on an i586, IMHO this is a bit of a PEBKAC issue. If you change CPUFLAGS to target a specific CPU, you should really rebuild all of world with it, not just a single program. In fact, you should rebuild all your ports too. I suggested maybe -march could be extended to also select seperate lib sub directories to at least trigger a link failure, rather than a silent apparent good compile of a bad binary. I think this would add a whole lot of complexity for very little gain, and still not save you from potential problems. You would really have to use the same approach for all system libraries, otherwise you might link in something from e.g. libc or libcrypto that was optimized for the wrong CPU. And I'm not even mentioning objects and/or libraries from ports... :) The compiler cannot automagically determine whether any object or library file you link into your program is fit to run on the CPU you are targeting, unless you would add information specifying the CPU type (and other particulars) to the object files themselves. In the end, it is up to you to make sure you do not mix incompatible object code. Having said all this, if you are worried particularly about the crt*.o files, then we could simply always build those with 'lowest common denominator' flags, like we do with e.g. the dynamic linker. I doubt very much that the startup code gains any performance by optimizing for higher CPU types. ___ 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: Issue with 'Unknown Error: -512'
On 2011-07-18 16:53, Brandon Falk wrote: In recent branches (confirmed with 224119) builds compiled with clang happen to throw 'Unknown error: -512' in a lot of places, making the system unusable. (Untested on gcc compiled systems). I have never seen this, neither with clang-compiled nor gcc-compiled systems. Can you please verify if it still occurs if you build your system with gcc? If you don't want (or can) rebuild the whole system, you can try to rebuild just your kernel with gcc, and see if the problems disappear. Originally I thought the problem was with specific programs, then I narrowed it down to file I/O, and now I've narrowed it down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every other time you run the program. Common issues, portsnap is affected, making it impossible to fetch/extract ports. As well as redirecting output in shells eg `echo 'hi' test` fails every other try. You have the same issue with text editors like `edit` where it fails every other save. There are no issues with `echo 'hi' test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. I have been running clang-compiled systems for a long time now, and have never seen this. It works fine here, I cannot reproduce any of your examples. Do you build with any special settings in make.conf or src.conf, particularly modified CFLAGS or COPTFLAGS? What is your architecture, i386 or amd64? Any other non-standard configuration or environment settings? ___ 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: [PATCH] __FreeBSD_cc_version in sys/cdefs.h
On 2011-07-04 18:30, Robert Millan wrote: This patch fixes a (harmless) warning whensys/cdefs.h is parsed by upstream version of GCC. -#if __FreeBSD_cc_version = 31 defined(__GNUC__) !defined(__INTEL_COMPILER) +#if defined(__FreeBSD_cc_version) __FreeBSD_cc_version = 31 defined(__GNUC__) !defined(__INTEL_COMPILER) As far as I can see, this code only gives warnings when compiled with gcc 4.5 or higher, and when using the -Wundef flag. Isn't it easier to just remove the -Wundef flag here? Additionally, it looks like the C standard is a bit vague about whether the preprocessor uses short-circuited boolean evaluation (although gcc's manual says it does), so I'm not sure whether this patch solves the problem properly either. ___ 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: PR bin/157732
On 2011-06-26 16:08, Christopher J. Ruwe wrote: In reaction to PR bin/157732 (http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/157732) I am investigating why traceroute does not trace hostnames greater in length than 64 chars. It turned out that a limit of 64 chars is coded into traceroute.c. From RFC2181 (http://tools.ietf.org/html/rfc2181#section-11) follows that a limit of 254 chars needs to be supported by software conforming to standard. Fixed in r223579. This will be MFC'd in a few days. ___ 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: [rfc] a few kern.mk and bsd.sys.mk related changes
On 2011-05-31 11:57, Alexander Best wrote: ... however i've often read messages - mostly by bruce evans - claiming that anything greater than -O will in fact decrease a kernel's ability to be debugged just as well as a kernel with -O. The critical option when -O2 is used is -fno-omit-frame-pointers, since removing frame pointers makes debugging impossible (on i386). With -O2 code is moved around and removed, so debugging is more difficult, but can still provide useful information. any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing as standard COPTFLAGS with debugging enabled for *all* archs? Most likely, the performance gain from -O2 is rather small, except for special cases, but the pain during debugging is increased a great deal. Even if you add frame pointers, with -O2 large pieces of code can be transformed, variables or even entire functions can be completely eliminated, and so on, making debugging much more difficult. ___ 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: [rfc] a few kern.mk and bsd.sys.mk related changes
On 2011-05-31 16:39, Alexander Best wrote: ... ...which leads me to the conclusion that -O should be set when DEBUG was defined: an all ARCHS. right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior? shouldn't -fno-omit-frame-pointer be set uncondtitionally on all archs? No, not unconditionally on all archs. Some arches have no problem debugging when gcc's frame pointer is turned off, namely arm, ia64, mips, powerpc and sparc, if I read the source correctly. On these arches, even -O already sets -fomit-frame-pointer. So, for all arches, if DEBUG is enabled, we could just use -O (as default only, if the user wants to override this for whatever reason, it should be honoured). just like -fno-strict-aliasing? That should only be needed in combination with -O2, if that is the default optimization (e.g. if DEBUG is not enabled). IMHO this option should not be forced, if users specify their own CFLAGS/COPTFLAGS. Summarizing, I would suggest: - If DEBUG is enabled, use plain -O by default, on all arches - If DEBUG is disabled, use -O2 -fno-strict-aliasing by default, on all arches. ___ 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: [rfc] a few kern.mk and bsd.sys.mk related changes
On 2011-05-31 17:26, Alexander Best wrote: ... so how about the following patch? Could you please try to not mix spacing and style changes with functional changes in this patch? It makes it more difficult to review. ___ 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: Include file search path
On 2011-03-29 23:20, m...@freebsd.org wrote:
So here's what I'm pondering. When I build a library, like e.g. libc,
where do the include files get pulled from? They can't (shouldn't) be
the ones in /usr/include, but I don't see a -nostdinc like for the
kernel. There are -I directives in the Makefile for
-I${.CURDIR}/include -I${.CURDIR}/../../include, etc., but that won't
remove /usr/include from the search path.
During the bootstrap stage, a copy of gcc (or clang) is built, that has
all default search paths for headers, libraries, etc, set relative to
${WORLDTMP}, usually /usr/obj/usr/src/tmp.
E.g:
$ /usr/obj/usr/src/tmp/usr/bin/gcc -v -E -x c /dev/null -o /dev/null
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719 [FreeBSD]
/usr/obj/usr/src/tmp/usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o
/dev/null
#include ... search starts here:
#include ... search starts here:
/usr/obj/usr/src/tmp/usr/include/gcc/4.2
/usr/obj/usr/src/tmp/usr/include
End of search list.
and:
$ /usr/obj/usr/src/tmp/usr/bin/gcc -print-search-dirs
install: /usr/obj/usr/src/tmp/usr/libexec/
programs:
=/usr/obj/usr/src/tmp/usr/bin/:/usr/obj/usr/src/tmp/usr/bin/:/usr/obj/usr/src/tmp/usr/libexec/:/usr/obj/usr/src/tmp/usr/libexec/:/usr/obj/usr/src/tmp/usr/libexec/
libraries: =/usr/obj/usr/src/tmp/usr/lib/:/usr/obj/usr/src/tmp/usr/lib/
This is a rather nasty hack, though. If we can make it work, we should
probably try using --sysroot instead, or alternatively, -nostdinc and
adding include dirs by hand. The same for executable and library search
paths, although I am not sure if there is a way to completely reset
those with the current options.
___
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: Include file search path
On 2011-03-30 17:26, Nathan Whitehorn wrote:
...
During the bootstrap stage, a copy of gcc (or clang) is built, that has
all default search paths for headers, libraries, etc, set relative to
${WORLDTMP}, usually /usr/obj/usr/src/tmp.
...
Since you need to build two compilers anyway (one for the current
system, to build the new one, and one to live in the new one, linked
against new libraries), I don't see that it's such a nasty hack.
The building itself is not a problem, of course, and it is even required
if you want to update anything in the toolchain itself.
However, we have added some custom #ifdef FREEBSD_NATIVE parts to
support this feature, so you cannot use stock gcc source to build such a
temporary compiler. This can be problematic if we ever want to be able
to use toolchains outside of the source tree.
___
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: libdispatch don't build on 8.2-RELEASE amd64
On 2011-03-02 16:40, Kostik Belousov wrote:
Rather, it is binutils 2.15 silently creating broken library.
2.21 refuses to do it.
Some object used to create the final dso was not built with -fPIC.
This is actually a problem of clang, in combination with libdispatch's
configure script. It tries to detect support for __private_extern__,
which is an Apple extension that serves the same goal on Darwin as the
visibility(hidden) attribute. If the test program does not compile,
it just defines __private_extern__ as visibility(hidden) instead, if
the toolchain supports that attribute.
However, clang has a problem that it accepts the __private_extern__
attribute even on non-Darwin OSes, while *not* marking the symbol
hidden. This will lead to the link error you are seeing here.
Can you please try the attached patch, which is a bit of a hack, but
works for now? Meanwhile, I'll prod the clang developers to disable
recognition of __private_extern__ on non-Darwin platforms.
Index: devel/libdispatch/Makefile
===
RCS file: /home/mirror/ncvs/ports/devel/libdispatch/Makefile,v
retrieving revision 1.10
diff -u -r1.10 Makefile
--- devel/libdispatch/Makefile 15 Dec 2009 21:06:37 - 1.10
+++ devel/libdispatch/Makefile 2 Mar 2011 20:26:28 -
@@ -86,8 +86,7 @@
RUN_DEPENDS+= clang:${PORTSDIR}/devel/llvm-devel \
${LOCALBASE}/lib/libBlocksRuntime.so:${PORTSDIR}/devel/compiler-rt
CONFIGURE_ARGS+= --with-blocks-runtime=/usr/local/lib
-CONFIGURE_ENV+=CC=clang
-MAKE_ENV+= CC=clang
+CONFIGURE_ENV+=CC=clang dispatch_cv_private_extern=no
.endif
.include bsd.port.post.mk
___
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: buildkernel error
On 2011-02-23 10:00, per...@pluto.rain.com wrote: Will either make buildworld or make kernel-toolchain accomplish anything if, as the OP said, s/he only updated the _kernel_ sources? No. You must update all sources atomically, or there is no guarantee it will build. ___ 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: buildkernel error
On 2011-02-22 08:30, gnehzuil wrote: I updated my kernel source code and try to make a new kernel using make buildkernel command. But I got an error as follow: ... ld:/usr/src/sys/conf/ldscript.i386:66: syntax error Your /usr/bin/ld is still at version 2.15, which is too old to parse the kernel linker script. In this case, first run make buildworld, or at least make kernel-toolchain before you attempt to build any kernels. ___ 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: Is svn.freebsd.org broken
On 2011-01-26 03:32, Mark Saad wrote: svn: In directory 'freebsd/tools/regression/usr.bin/jot' svn: Can't open file 'freebsd/tools/regression/usr.bin/jot/.svn/tmp/text-base/regress.wx.out.svn-base': No such file or directory Your local checkout is most likely broken. Subversion's working copy code is extremely fragile, unfortunately. :( Try running svn cleanup in your working copy, in most cases that fixes the failure. If not, just delete the whole working copy, and checkout from scratch again. ___ 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: Is it possible to have file removed upon process exit?
On 2010-11-25 21:14, Xin LI wrote: For certain applications it is sometimes desirable to (e.g. for unix domain sockets) have file removed when the process quit, regardless whether the process is quit cleanly. Is there a clean way to do this? Maybe your process could be the child of a parent which cleans up afterwards? (This is an analogy from real life. ;) ___ 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: Deterministic builds?
On 2010-11-14 21:22, Erik Cederstrand wrote: I'm curious as to why this might be useful? Would the mtime of the file not be be sufficient? I can only think of debugging purposes, but apart from the timestamp, two kernels with the same rev. would be bitwise identical, This does not have to be the case. For example, if you have have local modifications, or use different settings in make.conf or src.conf. Similarly, the host on which something is built can be interesting metadata, because not all hosts are equal. If it is useful, why not brand all binaries with a rev. number and a timestamp? There are compilers that automatically brand every binary with a built on timestamp. If you want to 'compare' such binaries, you simply need a tool that disregards the timestamps. ___ 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: libkvm: consumers of kvm_getprocs for non-live kernels?
On 2010-11-10 21:41, Ulrich Spörlein wrote: But, the kgdb file gnu/usr.bin/binutils/gdb/kvm-fbsd.c, where kvm_getprocs is probably called on a dead kernel is not even used during build! So I guess I'm staring at dead code here, any kvm people around that can clue me in? In gnu/usr.bin/binutils, the gasp, gdb and gdbreplay directories have been disconnected from the build for years now. I plan on garbage collecting them when merging the binutils-2.17 project branch (where they are already removed). ___ 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: ccache pausing in buildworld
On 2010-11-08 16:34, Alexey Shuvaev wrote:
Just FYI, you would see exact the same problem if you try to compile
i386 world on amd64-CURRENT with clang:
...
/src/lib/csu/i386-elf/crt1_s.S: Assembler messages:
/src/lib/csu/i386-elf/crt1_s.S:34: Error: suffix or operands invalid for `push'
/src/lib/csu/i386-elf/crt1_s.S:37: Error: `8(%ebp)' is not a valid 64 bit
base/index expression
/src/lib/csu/i386-elf/crt1_s.S:38: Error: suffix or operands invalid for `push'
/src/lib/csu/i386-elf/crt1_s.S:39: Error: `4(%ebp)' is not a valid 64 bit
base/index expression
/src/lib/csu/i386-elf/crt1_s.S:40: Error: suffix or operands invalid for `push'
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)
*** Error code 1
...
As far as I understand this, there is no clang cross-compiler support
at the moment. So compiler generates (somehow) i386 assembler code
which amd64 assembler does not like. Looks like something similar happens
here too...
Have you read http://wiki.freebsd.org/BuildingFreeBSDWithClang, which
suggests to put:
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
in your /etc/src.conf (or make.conf, depending on your preference)?
If you use that, it should work, at least for the build32 stage of
buildworld on amd64. This workaround is only needed on amd64, not for
i386.
___
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: ccache pausing in buildworld
On 2010-11-08 14:48, Emanuel Haupt wrote:
After updating and zeroing the cache files the a build of RELENG_8_1 fails with:
CC='/usr/local/libexec/ccache/world-cc' mkdep -f .depend -a
-I/usr/src/lib/csu/i386-elf/../common
-I/usr/src/lib/csu/i386-elf/../../libc/include /usr/src/lib/csu/i386-elf/crti.S
/usr/src/lib/csu/i386-elf/crtn.S
/usr/local/libexec/ccache/world-cc -O2 -pipe
-I/usr/src/lib/csu/i386-elf/../common
-I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings
-Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline
-Wnested-externs -Wredundant-decls -Wno-pointer-sign -c
/usr/src/lib/csu/i386-elf/crti.S
/usr/local/libexec/ccache/world-cc -O2 -pipe
-I/usr/src/lib/csu/i386-elf/../common
-I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings
-Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline
-Wnested-externs -Wredundant-decls -Wno-pointer-sign -c
/usr/src/lib/csu/i386-elf/crtn.S
/usr/local/libexec/ccache/world-cc -O2 -pipe
-I/usr/src/lib/csu/i386-elf/../common
-I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings
-Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline
-Wnested-externs -Wredundant-decls -Wno-pointer-sign -DGCRT -c -o gcrt1_c.o
/usr/src/lib/csu/i386-elf/crt1_c.c
/usr/local/libexec/ccache/world-cc -O2 -pipe
-I/usr/src/lib/csu/i386-elf/../common
-I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings
-Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline
-Wnested-externs -Wredundant-decls -Wno-pointer-sign -c
/usr/src/lib/csu/i386-elf/crt1_s.S
/usr/src/lib/csu/i386-elf/crt1_s.S: Assembler messages:
/usr/src/lib/csu/i386-elf/crt1_s.S:34: Error: suffix or operands invalid for
`push'
/usr/src/lib/csu/i386-elf/crt1_s.S:37: Error: `8(%ebp)' is not a valid 64 bit
base/index expression
/usr/src/lib/csu/i386-elf/crt1_s.S:38: Error: suffix or operands invalid for
`push'
/usr/src/lib/csu/i386-elf/crt1_s.S:39: Error: `4(%ebp)' is not a valid 64 bit
base/index expression
/usr/src/lib/csu/i386-elf/crt1_s.S:40: Error: suffix or operands invalid for
`push'
*** Error code 1
This is during the 32-bit build stage on amd64? If so, what will
happen, depends on how you defined CC. Makefile.inc1 defines CC as an
environment variable for a sub-make, using something like:
CC=${CC} -m32 ${LIB32CPUFLAGS} -DCOMPAT_32BIT \
-isystem ${LIB32TMP}/usr/include/ \
-L${LIB32TMP}/usr/lib32 \
-B${LIB32TMP}/usr/lib32
However, if you either put CC=/usr/local/libexec/ccache/world-cc on the
make command line, or in /etc/src.conf or /etc/make.conf as an
unconditional assignment, it will *always* override the above setting
through the environment, causing the 32-bit build stage to fail.
If this is the case, you could use the same construction I have been
using to get clang to build the 32-bit stage properly, e.g. put:
.if !defined(CC) || ${CC} == cc
CC=/usr/local/libexec/ccache/world-cc
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=/usr/local/libexec/ccache/world-cc
.endif
in your src.conf or make.conf, as a workaround.
Really fixing this issue requires rather ugly hackery in Makefile.inc1,
bsd.*.mk and so on, though... :-/
___
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: csup or svn
On 2010-09-27 04:47, Aryeh Friedman wrote: I currently use: csup -h cvsup9.us.freebsd.org /usr/share/examples/cvsup/cvs-supfile and when I just ran it I got: Append to CVSROOT-src/access Edit CVSROOT-src/access,v Segmentation fault (core dumped) Unfortunately, the access,v file in the master repository is still corrupted, so every time it gets an update, csup will die on it. The short term solution is to run rm -f CVSROOT-src/access,v just before your csup command line. The long term solution consists of 1. fixing the master repo, and 2. fixing csup so it doesn't die on corrupt ,v files... ___ 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: Optimized memcmp failure.
On 2010-08-10 10:08, Clement LECIGNE wrote: It describes various memcmp() implementations of some OSes. FreeBSD is mentionned at the end of the post and it warns about the fact that gcc uses its own builtin memcmp() function when optimization (from O1 to O3) is set. Unfortunately the gcc builtin memcmp() seems less optimized (at least for i386 and amd64) than the FreeBSD memcmp() implementation (found in libc). Some of the libc memcmp/cpy/etc implementations are hand-optimized assembly, and those might very well be faster than the built-in ones, for the general case. However, in some cases, the compiler has more information about the context in which a copy operation is taking place, and might be able to simplify the copy so much that it is more efficient than the libc memcpy. That said, the mentioned security issue is about sensitive information (the length of secret keys, etc) possibly being derived from timing memcpy calls. In that case it would probably even be better to let the compiler inline that code, since you cannot simply hook the libc memcpy function anymore. :) Better solutions for this (and similar issues) are more costly: you have to go through all code handling sensitive data carefully, identify the memcpy/memcmp/etc calls that could possibly leak secret information, and replace those with 'timing insensitive' versions. OpenBSD just went through a whole bunch of these checks... ___ 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 problem with int64_t variables
On 2010-07-11 16:46, Gabor Kovesdan wrote: I have two int64_t variables in kernel code, first is stored internally and the second one is passed from a syscall argument. When I print them with printf %lld modifier, the internal one behaves correctly but the other one I pass from a syscall has a corrupted value. If I pass 1, it prints out 3735348794091372545. I'm not doing anything special with it just reading it out from the struct that was generated with make sysent. Since 3735348794091372545 is 0x33d69ff1, it looks like the upper word got corrupted somehow. Maybe some part of it got non-atomically assigned? Maybe the wrong word was read? It is hard to tell without code... :) ___ 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: GSoC: Making ports work with clang
On 2010-05-03 12:38, C. Bergström wrote: What's really the goal here? What problem are you working to solve? May I humbly say that building software with a different compiler in itself doesn't really accomplish anything. Of course it does. It forces you to make your software portable. ___ 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: GSoC: Making ports work with clang
On 2010-05-03 13:19, C. Bergström wrote: Of course it does. It forces you to make your software portable. and your point is? Are you trying to say that s/building/porting/ between compilers is going to magically make the software (have less bugs, more performance or better robustness) No, it gives you the choice of which compiler to use. Porting could be a means-to-an-end, but still it's not an end goal.. I'm digging at what's the end goal.. After it's all ported what magically happens? You can then switch compilers freely, or at least, without too much effort. ___ 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: GEOM_ULZMA
On 2010-03-04 15:28, Joerg Sonnenberger wrote: It is still measurable slower than gzip and it is certainly not free. Ehm, the LZMA SDK is in the public domain, how much more free would you want it? ___ 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: GEOM_ULZMA
On 2010-03-02 09:47, Alexandr Rybalko wrote: Definiatelly separately, not sure where. There is ongoing discussion somwhere on importing this algorithm to the base for tar(1) to use, it would be best to have only one copy of code in the tree. I have already said, that it would be good for embedded platforms have only one copy of the code for the kernel and userland. It is not thought of how done it. I think Pawel means the *source* code in this case, not the executable code. E.g. lzma source should most likely go under /usr/src/contrib, and be built separately for kernel and userland. ___ 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: Checksum mismatch -- will transfer entire file
On 2010-01-03 01:15, Matthias Andree wrote: I suspect (without any proof) that this is only for src, because that is converted from a live SVN repository to CVS for the sake of CVSup distribution, while all other repositories are still CVS natively. Every now and then, I also see a file from ports corrupted: ports/Mk/bsd.port.mk,v: Checksum mismatch -- will transfer entire file ports/Mk/bsd.port.mk,v: Checksum mismatch -- will transfer entire file ports/Mk/bsd.port.mk,v: Checksum mismatch -- will transfer entire file ports/Mk/bsd.port.mk,v: Checksum mismatch -- will transfer entire file ports/Mk/bsd.port.mk,v: Checksum mismatch -- will transfer entire file projects/pkgtools/bin/pkgdb,v: Checksum mismatch -- will transfer entire file projects/pkgtools/bin/portupgrade,v: Checksum mismatch -- will transfer entire file projects/pkgtools/NEWS,v: Checksum mismatch -- will transfer entire file projects/pkgtools/bin/portupgrade,v: Checksum mismatch -- will transfer entire file projects/pkgtools/lib/pkgmisc.rb,v: Checksum mismatch -- will transfer entire file projects/pkgtools/lib/pkgtools.rb,v: Checksum mismatch -- will transfer entire file projects/pkgtools/bin/portupgrade,v: Checksum mismatch -- will transfer entire file ports/Mk/bsd.port.mk,v: Checksum mismatch -- will transfer entire file ports/Mk/bsd.port.mk,v: Checksum mismatch -- will transfer entire file projects/pkgtools/bin/portupgrade,v: Checksum mismatch -- will transfer entire file ports/Mk/bsd.port.mk,v: Checksum mismatch -- will transfer entire file This was grepped through the last few months. Are any of these specific files 'imported' from svn, by any chance? ___ 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: Checksum mismatch -- will transfer entire file
On 2009-12-31 04:32, Victor Sudakov wrote: I cvsup the FreeBSD CVS repository daily from cvsup.ru.freebsd.org. Both the client and the server run CVSup Software version: SNAP_16_1h, Protocol version: 17.0. Recently I noticed that there are lots of messages Checksum mismatch -- will transfer entire file about all kinds of downloaded files, e.g. src/lib/libc/posix1e/acl_delete_entry.c,v: Checksum mismatch -- will transfer entire file I also see a bunch of these, almost every time I do a csup. Looking back in my logs, I see that it goes back until at least 2009-07-05... ___ 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: Spot the error
On 2009-08-05 02:15, Mel Flynn wrote: I would expect Unable to load fs: + ENOENT. I was asking if this was fixable, cause it looked like the code has been abstracted to the point that specific errors were hard, but maybe I missed something. It does not seem easily fixable. The problem is that the mount command simply prints out the error of the system call, and doesn't have any idea which of the (many) parameters was wrong. You could change the returned error in this particular case to ENOENT, of course, but that might be considered even more confusing. Like, What do you mean, that SCSI disk doesn't exist? It's right there in /dev! One could also argue for EINVAL, but there's the bikeshed again... :) ___ 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: Spot the error
On 2009-08-04 22:45, Mel Flynn wrote: % mount -t msdofs /dev/label/camera ~/camera mount: /dev/label/camera : Operation not supported by device I would expect something along the lines of unknown file system type. Is this fixable? Yes, just use msdosfs instead. ;) That said, it looks like ENODEV is returned by vfs_domount(), whenever the fs type is not found in the list of supported filesystems: [...] if (fsflags MNT_ROOTFS) vfsp = vfs_byname(fstype); else vfsp = vfs_byname_kld(fstype, td, error); if (vfsp == NULL) return (ENODEV); [...] Note that in the case when vfs_byname_kld() gets called, the error it returns is silently thrown away. What a pity. :) In any case, you could paint a lot of bikesheds about which error code from errno.h would be most suited for this situation, unfortunately. And there isn't a special unknown file system error code, either... ___ 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: What's changed between 7.1 and 7.2
On 2009-07-08 19:28, Robert Watson wrote: This is effectively debugging output that slipped into the release and shouldn't have. I believe it's now removed in 8.x, I'm not sure it's been MFC'd to 7.x yet. It was indeed removed, with r193131. The diff here: http://svn.freebsd.org/viewvc/base/head/sys/geom/label/g_label.c?view=patchr1=193131r2=193130pathrev=193131 should apply to 7.x without problems. ___ 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: bin/134694: gives false-positive when unable to obtain socket [WAS: sshd(8) - alert user when fails to execute from rc.d]
On 2009-05-20 12:19, Eygene Ryabinkin wrote: You seem to mix two things: binding to the port and the output from rc.d 'status' command. Binding to the port is done by SSH by the bind(2) system call and if something is already listening on the given address, the socket won't be bound, so SSH daemon terminates. I think what might be confusing, is the fact that sshd dies due to bind() failing, and it should; but you will only see this in the syslog, NOT on the command line. E.g. the /etc/rc.d/sshd script will NOT give an error, because the /usr/bin/sshd it calls will fork, and as soon as the fork is okay, the original instance with exit with 0. The forked instance is what will die on bind(), so you will not see any failures from it. ___ 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: bin/134694: gives false-positive when unable to obtain socket [WAS: sshd(8) - alert user when fails to execute from rc.d]
On 2009-05-20 13:18, Tobias Fendin wrote: Does the child really die? I did a little test: # /etc/rc.d/sshd status sshd is not running. # nc -l 22 /tmp/ssh_test [1] 1733 # /etc/rc.d/sshd start Starting sshd. # /etc/rc.d/sshd status sshd is running as pid 1740. This is because sshd binds to both IPv4 and IPv6 ports. The IPv4 bind fails, as you will see in syslog, while the IPv6 bind succeeds. Thus sshd keeps on running. If you start two nc's (I don't know any way to do this with one instance), e.g.: nc -4 -l 22 /tmp/ssh_test4 nc -6 -l 22 /tmp/ssh_test6 and then try starting sshd, you should see it quit. ___ 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: bin/134694: gives false-positive when unable to obtain socket [WAS: sshd(8) - alert user when fails to execute from rc.d]
On 2009-05-20 16:40, Glen Barber wrote: sshd was listening on :25, both IPv4 and IPv6 sendmail was listening on :25 (because I had forgotten to disable it) The system boots, and sendmail starts before sshd. When sshd starts (or tries to) there is no console output that it had failed. The only way you realize it is not running, is when you cannot remotely log in. Yes, this is unfortunate, but normal, as I explained in an earlier post. The sshd process does not return any error (and thus the /etc/rc.d script doesn't either), because it has no way to know that its forked copy died. The solution to this PR is don't run stuff on conflicting ports. :) ___ 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: usinig cvs diff to make a patch
On 2009-02-03 20:17, Aryeh M. Friedman wrote: I use a local cvs repo and I have modified a port and which to submit an update for it how do I generate a patch file with cvs (cvs diff seems to give a unusable format)? Use cvs diff -up for unified diff format, with function prototypes. ___ 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: Kernel Module - GCC Requires memmove
On 2009-01-22 02:14, Nate Eldredge wrote:
I vaguely recall Linux having a policy that compiling the kernel without
optimization was not supported, possibly because of situations like this.
No, Linux has its own implementations of mem{cmp,cpy,move,set}, both in
fallback C versions, and optimized versions for several arches.
Compiling Linux without optimization will fail at the linking stage, due
to extern inline functions in header files, without implementation in
separate .c files.
___
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: Kernel Module - GCC Requires memmove
On 2009-01-21 13:12, Andrew Brampton wrote:
The .ii file (post-processed source) did NOT mention memmove at all.
So I found it very odd that an undefined symbol existed in the object
file. So then I looked in the .s file (asm), and it was clearing
making a single call to memmove.
This can (amongst others) occur if you assign structs, e.g.:
int test(void)
{
struct foo {
char bar[100];
} a, b;
b = a;
}
Compile this with gcc -O0 -S, and you'll see it generates a call to
memcpy().
___
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: lzo2 shows insane speed gap
On 2008-12-29 22:25, Christian Weisgerber wrote: On the slow machines, the tests also consume a lot of system time. I've seen figures from 20 to 50%. However, ktrace shows nothing out of the ordinary. What's up with the memory on these machines? Lzo tends to take insane amounts ___ 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: lzo2 shows insane speed gap
On 2008-12-30 00:17, Dimitry Andric wrote: What's up with the memory on these machines? Lzo tends to take insane amounts Duh, nevermind... I'm confusing this with lzma. :) Sorry for the noise. ___ 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: strdup(NULL) supposed to create SIGSEGV?
On 2008-04-23 07:40, Garrett Cooper wrote: I made an oops in a program, which uncovered feature in strdup(2) that I wasn't aware of before. So I was wondering, is strdup(pointer = NULL) supposed to segfault should this just return NULL and set errno? It could, in fact, tear up the fabric of the universe, or blow up your machine, if it wanted. :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security Flaw in Popular Disk Encryption Technologies
On 2008-02-23 02:08, Atom Smasher wrote: article below. does anyone know how this affects eli/geli? from the geli man page: detach - Detach the given providers, which means remove the devfs entry and clear the keys from memory. does that mean that geli properly wipes keys from RAM when a laptop is turned off? This is a physical attack, and there's nothing you can do in software to prevent it. Of course geli or other software can attempt to erase the keys from RAM as soon as it's done using them, but it won't prevent hijacking them beforehand. It's the same with all physical attacks: hardware sniffers, keyloggers, TEMPEST, etc. You need physical (hardware) protection to secure against these, not software. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: encrypted executables
On 2008-02-19 02:18, Jerry Toung wrote: anybody knows of a tool to encrypt executables under FreeBSD? may be from the ports? I am not talking about simple file encryption. Can you elaborate on what you *are* talking about then? Some security-by-obscurity scheme, perhaps? :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stale mount on disconnected device: how to delete it?
Yuri wrote: I had USB camera connected and recognized as umass0 and mounted as /mnt/camera on /dev/da0s1. Camera was disconnected while it was still mounted. I've understood that the only solution to this currently is don't do that then. :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] Wiki for discussing P35/IHC9(R)/SATA issues set up
Dag-Erling Smørgrav wrote: Aryeh M. Friedman [EMAIL PROTECTED] writes: http://www.flosoft-systems.com/wiki/index.php What's wrong with wiki.freebsd.org? To paraphrase: The nice thing about wiki's is that there are so many to choose from. :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in propagate_priority w/ postgresql under heavy load
On 2005-09-01 at 19:02:06 Koen Martens wrote: Anyway, it seems the dump should've gone to the swap partition, but i'm into multi-user mode again so i guess i'll have to wait for another panic to obtain it? Yes. By now, if any dump was ever written to your swap partition, it will most probably have been overwritten by your heavy postgres activity. :) In RELENG_6, the dump device is chosen automagically during boot by /etc/rc.d/dumpon, but this is (alas) not the case in RELENG_5_x, so you'll have to manually specify it in /etc/rc.conf, i.e: dumpdev=/dev/ad0s1b Then make sure you have enough space in /var/crash, and try to reproduce your panic... Also, I think I read somewhere that there used to be problems with dumping and 3Ware RAID cards (you seem to be using one according to your kernel config, but you apparently didn't post a dmesg). However, it looks like revision 1.22.2.1 of src/sys/dev/twe/twe.c fixed that: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/twe/twe.c?rev=1.22.2.1content-type=text/x-cvsweb-markup Just to be sure, can you check if you got this version of twe.c, or 1.22.2.2 (which seems to be the RELENG_5_4 version, and thus it should be fixed). pgpiU5sTzAb9H.pgp Description: PGP signature
Re: bus error in strsep
On 2005-07-06 at 21:41:00 Stefan Sperling wrote: char *c = whats:your:name:buddy?; made type. that should read that is read only copy :) Dark corners of C... So it's my own fault, as usual :) Actually, this dark corner was enlightened not so long ago. String constants used to be writable for years, until someone decided that it was better not to. :) Anyway, you can get the old (deprecated!) behaviour by using the -fwritable-strings option to gcc. pgpOjDCRlF0Rw.pgp Description: PGP signature
Re: Long uptime 5.2.1 server
On 2005-06-18 at 10:30:58 Kevin Day wrote: We've got a FreeBSD 5.2.1-RELEASE-p1 server that's been up for 460 days now, with pretty heavy use the whole time (70GB+ per day http traffic, 140 hits/sec, etc). Funny that some people insist on complaining about 5.x instability. :P pgpGnWaJZ7x7h.pgp Description: PGP signature
Re: Star FreeBSD
On 2005-02-10 at 20:08:10 Joerg Schilling wrote: Is there a chance to have star integrated into FreeBSD? Tim Kientzle already produced a BSD-licensed version of tar, having many features: http://people.freebsd.org/~kientzle/libarchive/ (He even mentions you on this page :) So unless your program offers essential features that his doesn't, I would guess it won't have much chance. pgpVk8aefg1VH.pgp Description: PGP signature
Re: Weird problem with midnight commander (Freebsd 5.3)
On 2005-02-03 at 00:34:50 Aleksander Rozman - Andy wrote: I am having weird problem. I have installed FreeBSD 5.3 on several machines, and on two of those machines midnight commander has serious problems. When I run it, it needs a long time to start, and I mean long, about 5 minutes or so. Maybe you can try ktrace(1) on the program, to see what it is doing during its long startup. Usually, with things like this, it's some sort of network problem, mostly DNS. pgpbmGANBEwhD.pgp Description: PGP signature
Re: Protection from the dreaded rm -fr /
On 2004-10-02 at 10:19:28 Giorgos Keramidas wrote: His idea was remarkably simple, so I went ahead and wrote this patch for rm(1) of FreeBSD: Of course, your work is commendable, but isn't is much simpler to just not type commands like that? I mean, rm -rf /etc or rm -rf /bin are just as bad, but do you really want to be checking for all possible `bad' deletions? That way, we'll start to look like some software from Redmond... :) pgpzhYWqSGeM6.pgp Description: PGP signature
Re: Question for C++ Experts
On 2004-07-26 at 21:55:32 Ryan Sommers wrote: The problem I am running into is that it seems to be illegal to call a pure virtual function from an abstract base contructor. This is because you shouldn't call virtual functions from constructors, unless you know what you're doing. :) Try using exceptions, or two-phase initialization. And read a C++ FAQ for more info, i.e.: http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.3 There's lots more in there, also explaining your other questions. But this is quite offtopic for this list... pgpTB6DXp2bjZ.pgp Description: PGP signature
Re: gcc strangeness
On 2004-07-11 at 19:06:32 Dmitry Morozovsky wrote: 1.00 1.000 0 2.00 2.000 1 3.00 3.000 2 4.00 4.000 3 5.00 5.000 5 6.00 6.000 6 7.00 7.000 7 8.00 8.000 7 9.00 9.000 8 9.99 10.000 9 Yes, this is completely normal if you use IEEE floating point, due to decimal - binary conversion and other accumulating rounding errors. In other words, floating point calculations will almost never be exact... This is not a gcc problem. In fact, I can even reproduce your output under Windows using a Microsoft C compiler! :) pgpniUit3rNUP.pgp Description: PGP signature
Re: /bin/ls sorting bug?
On 2004-06-19 at 19:50:07 Scott Mitchell wrote: (562) tuatara:/tmp/foo $ ls -lt total 0 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:48 c -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 b -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 d -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 e -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 f -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 g -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 h -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 i -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 j -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 a -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 k Can you please show the output of ls -ltT ? pgpXwTsAylawE.pgp Description: PGP signature
Re: lseek to EOF always 0 for devices
On 2004-05-01 at 13:37:04 Jens Schweikhardt wrote:
I'm not sure if I'm trying something impossible here. I want to find the
size in bytes of a disk special device, eg /dev/da0, /dev/da0s1,
/dev/da0s1a, /dev/vinum/usr and so on.
I have no idea why lseek'ing in the devices doesn't work, but try
using ioctl(2) with DIOCGMEDIASIZE (from sys/disk.h), this works
fine for me:
#include stdio.h
#include fcntl.h
#include unistd.h
#include sys/disk.h
int main (int argc, char **argv)
{
int fd;
off_t len;
if (argc != 2)
return 1;
if ((fd = open (argv[1], O_RDONLY)) 0) {
perror (argv[1]);
return 1;
}
if (ioctl (fd, DIOCGMEDIASIZE, len) == -1) {
perror (DIOCGMEDIASIZE);
return 1;
}
printf (%lld\n, (long long)len);
close (fd);
return 0;
}
pgp0.pgp
Description: PGP signature
Re: GCC include files conundrum.
On 2004-03-15 at 14:56:33 David Gilbert wrote: In your particular case, maybe you could add a copy of strstream.h as a patch to the port into the build directory and reference it as strstream.h instead of strstream.h. Thus the system libstdc++ headers do not need to be polluted. Finally a helpful idea I hadn't explored yet, thank-you. I've just sent in a PR with an analogous patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=64310 Please check if this works for you. pgp0.pgp Description: PGP signature
Re: pciconf -lv - /dev/pci error
On 2003-12-31 at 19:01:06 Robert Watson wrote: superuser. I received this error: [EMAIL PROTECTED] 09:12:42 root]# pciconf -lv pciconf: /dev/pci: Operation not permitted pciconf -lv appears to cause pciconf to open /dev/pci writable: 731 pciconf CALL open(0x8049a55,0x2,0) 731 pciconf NAMI /dev/pci 731 pciconf RET open -1 errno 13 Permission denied And, of course, it's not writable by non-root. Didn't the original poster have a problem when he actually was root? Of course I agree that pciconf should only open the device r/w if strictly necessary, but I was just thinking his problem lay elsewhere. pgp0.pgp Description: PGP signature
Re: 5.1 - 5.2 upgrade, Promise FastTrak device /dev/ar0 missing?
On 2003-12-28 at 14:51:42 Kevin A. Pieckiel wrote: Included is my dmesg output from the 5.1 kernel and my kernel config file SAMSON for the 5.1 kernel. Any help would be appreciated. You need device ataraid in your config file.. Thanks. That worked great. For some reason I missed this bit... This is a good example: making a copy of GENERIC some time in the past, and forgetting to update it when you upgrade the whole OS. :) In the latest version of GENERIC, ataraid is included by default. Maybe it would be nice to have a system for this, like what is used for /etc/rc.conf, i.e. making your kernel config file simply include GENERIC, and then only adding/removing those items you want to be changed from the defaults. pgp0.pgp Description: PGP signature
Re: FBSD 5-CURRENT: Kernel Makefile.inc1 Error
On 2003-12-08 at 23:50:03 Damian Gerow wrote: * make buildworld * make buildkernel * make installkernel * reboot to single-user * make installkernel * mergemaster * reboot I think you want that second 'installkernel' to actually be an 'installkernel'. I'd advise some more coffee, you probably meant 'installworld' on the second instance. ;) Btw, I've also seen some reports, and experienced, that the first make installkernel can also fail with signal 12's, probably due to the new 'install' executable using some not-yet-available system calls. If you are stuck in this case, you can manually copy the kernel file to its destination, boot from it in single user mode, and run installkernel from there. That saved my neck, at least... pgp0.pgp Description: PGP signature
Re: gcc bug? Openoffice port impossibel to compile on 4.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-05-28 at 14:12:34 Dag-Erling Smorgrav wrote: have you tried -traditional? gcc 3.1 release notes: The -traditional C compiler option has been deprecated and will be removed in GCC 3.3. (It remains possible to preprocess non-C code with the traditional preprocessor.) gcc 3.3 release notes: The -traditional C compiler option has been removed. It was deprecated in 3.1 and 3.2. (Traditional preprocessing remains available.) So, I'd guess in gcc 3.x, this whole option is completely unmaintained and therefore you'd be quite on your own if you try to compile anything seriously with -traditional... :( 2.95.x is probably not going to go away for a long time. :) -BEGIN PGP SIGNATURE- Version: 6.5.8ckt iQA/AwUBPtSsxbBeowouIJajEQLSLgCaAzFTNq08M0cFkBXBHfOWMW9EVnoAoJYH Y1nnQdgORVP5+olXw+VekOYm =CJj2 -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in make(1)?
On 2003-04-03 at 23:23:00 Pawel Jakub Dawidek wrote: IMHO make(1) should put .o files in current directory _and_ look for them there when producing an executable file. Right? I think this is more of a gcc/g++ problem/feature. :) The info page says: If `-o' is not specified, the default is to put an executable file in `a.out', the object file for `SOURCE.SUFFIX' in `SOURCE.o', its assembler file in `SOURCE.s', and all preprocessed C source on standard output. So at first glance I would say: gcc -c some/weird/path/file.c outputs the file some/weird/path/file.o. But it doesn't, it puts the object file in the current directory... This is probably a feature, and if you change it, I guess a lot of stuff will break. :) Therefore, the simplest solution is to specify -o options everywhere. I've attached a patch for /usr/share/mk/sys.mk that does this, but please beware, it might break stuff which *expects* output files to always be put in the current directory. OTOH, make(1) itself seems to be consistent with relative pathnames; if you tell it a rule to create .b files from .a files, it will correctly try to use that rule to convert some/path/file.a into some/path/file.b (and NOT ./file.b). sys.mk.diff Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Best way to install on Dozens of boxes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2002-07-04 at 14:19:48 Michael Scheidell wrote: MS If I want to install FBSD 4.5 on dozens of identical boxes, what MS is the best way? Please see this paper: Installing and Maintaining clusters of servers using PXE and Rsync, by Cor Bosman. http://www.nluug.nl/events/sane2002/papers/SANE.ps Cheers, - -- Dimitry Andric [EMAIL PROTECTED] PGP Key: http://www.xs4all.nl/~dim/dim.asc Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2E2096A3 Lbh ner abj va ivbyngvba bs gur QZPN -BEGIN PGP SIGNATURE- Version: 6.5.8ckt http://www.ipgpp.com/ Comment: http://www.gn.apc.org/duncan/stoa_cover.htm iQA/AwUBPSQ5C7BeowouIJajEQKI3gCglBKpX2OlfMnFoMNx2+V/qh8SF18AmQFp SkLI1s+2ofIjamXM7PV3X0E1 =jM8y -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
