Re: error: your copy of LLDB does not support scripting.
On Fri, 2015-10-09 at 17:06 -0700, Craig Rodrigues wrote: > Hi, > > In /etc/make.conf, I put WITH_LLDB="yes" > and rebuilt/reinstalled the world. > > I then tried: > > (lldb) script > error: your copy of LLDB does not support scripting. > > Is there a way to configure LLDB with script support? I think you need to use the ports lldb. -- Rui Paulo ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Kernel compilation failures with gcc 4.9
On Mar 31, 2015, at 14:04, Craig Rodrigues rodr...@freebsd.org wrote: Hi, I put this in make.conf: NO_WERROR=yes WERROR= WITHOUT_BOOT=yes WITHOUT_RESCUE=yes and used this script to build: https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh I managed to build a lot of stuff, but then got build failures in the aesni part of the kernel build. See the full build log here: https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/30/console I think this is the error: In file included from /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/mm_malloc.h:27:0, from /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/xmmintrin.h:34, from /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/emmintrin.h:31, from /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/wmmintrin.h:31, from /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/modules/aesni/../../crypto/aesni/aesni_ghash.c:74: /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include/stdlib.h:93:7: error: conflicting types for 'free' void free(void *); ^ In file included from /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/crypto/aesni/aesni.h:33:0, from /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/modules/aesni/../../crypto/aesni/aesni_ghash.c:69: /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/sys/malloc.h:177:6: note: previous declaration of 'free' was here void free(void *addr, struct malloc_type *type); It shouldn't be using the stdlib when it's built with -ffreestanding or -nostdlib. Can you make sure? -- Rui Paulo ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Fails to build sys/i386/boot2 with gcc 4.9
On Mar 29, 2015, at 13:29, Craig Rodrigues rodr...@freebsd.org wrote: Just out of curiousity, what is it about newer compilers that cause the size of boot2 to increase so much? Code generation is different, especially with regards to optimisations. Longer code might be faster because the compiler decided to inline a few functions. Unfortunately, I never saw any difference between -Os and -O2 in all of my tests (boot2 and other code). -- Rui Paulo ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
[Differential] [Accepted] D1819: libdwarf: Handle .rel relocations
rpaulo added a subscriber: rpaulo. rpaulo accepted this revision. rpaulo added a reviewer: rpaulo. rpaulo added a comment. This revision is now accepted and ready to land. Reviewed. REVISION DETAIL https://reviews.freebsd.org/D1819 To: emaste, gnn, rpaulo Cc: rpaulo, freebsd-toolchain ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
[Differential] [Accepted] D1682: Preserve hard symbolic links when modifying source file
rpaulo accepted this revision. rpaulo added a reviewer: rpaulo. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1682 To: emaste, rpaulo Cc: freebsd-toolchain ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
[Differential] [Changed Subscribers] D1428: readelf: Handle note types from different operating systems
rpaulo added a subscriber: rpaulo. rpaulo added a comment. This looks odd. Why are we relying on magic numbers instead of constants/enums like before? REVISION DETAIL https://reviews.freebsd.org/D1428 To: emaste Cc: rpaulo, freebsd-toolchain ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
[Differential] [Commented On] D1428: readelf: Handle note types from different operating systems
rpaulo added a comment. ! In D1428#5, @emaste wrote: ! In D1428#3, @rpaulo wrote: This looks odd. Why are we relying on magic numbers instead of constants/enums like before? Some of the constants in the previous version are Linux-specific, and don't exist in our ELF headers. We could make up our own constants (e.g. NT_LINUX_AUXV) but it doesn't seem like that would provide much value. The same constant name may have different values on different OSes. The Linux note types are Linux specific. Are you saying that FreeBSD reuses them ? REVISION DETAIL https://reviews.freebsd.org/D1428 To: emaste Cc: rpaulo, freebsd-toolchain ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Is this a compiler bug?
On Sep 21, 2014, at 18:19, Steve Kargl s...@troutmask.apl.washington.edu
wrote:
#include stdio.h
#include stdint.h
int
main(void)
{
uint16_t i;
i = 0x3ff0+63; printf(%x\n, i);
i = 0x3ff1+63; printf(%x\n, i);
i = 0x3ff2+63; printf(%x\n, i);
i = 0x3ff3+63; printf(%x\n, i);
i = 0x3ff4+63; printf(%x\n, i);
i = 0x3ff4+63; printf(%x\n, i);
i = 0x3ff6+63; printf(%x\n, i);
i = 0x3ff7+63; printf(%x\n, i);
i = 0x3ff8+63; printf(%x\n, i);
i = 0x3ff9+63; printf(%x\n, i);
i = 0x3ffa+63; printf(%x\n, i);
i = 0x3ffb+63; printf(%x\n, i);
i = 0x3ffc+63; printf(%x\n, i);
i = 0x3ffd+63; printf(%x\n, i);
i = 0x3ffe+63; printf(%x\n, i);
i = 0x3fff+63; printf(%x\n, i);
return 0;
}
Looks like it. Please file a bug report with LLVM.
--
Rui Paulo
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Is this a compiler bug?
On Sep 21, 2014, at 18:38, Rui Paulo rpa...@me.com wrote:
On Sep 21, 2014, at 18:19, Steve Kargl s...@troutmask.apl.washington.edu
wrote:
#include stdio.h
#include stdint.h
int
main(void)
{
uint16_t i;
i = 0x3ff0+63; printf(%x\n, i);
i = 0x3ff1+63; printf(%x\n, i);
i = 0x3ff2+63; printf(%x\n, i);
i = 0x3ff3+63; printf(%x\n, i);
i = 0x3ff4+63; printf(%x\n, i);
i = 0x3ff4+63; printf(%x\n, i);
i = 0x3ff6+63; printf(%x\n, i);
i = 0x3ff7+63; printf(%x\n, i);
i = 0x3ff8+63; printf(%x\n, i);
i = 0x3ff9+63; printf(%x\n, i);
i = 0x3ffa+63; printf(%x\n, i);
i = 0x3ffb+63; printf(%x\n, i);
i = 0x3ffc+63; printf(%x\n, i);
i = 0x3ffd+63; printf(%x\n, i);
i = 0x3ffe+63; printf(%x\n, i);
i = 0x3fff+63; printf(%x\n, i);
return 0;
}
Looks like it. Please file a bug report with LLVM.
Actually, the same compile error exists with gcc 4.7. I'm not sure why.
--
Rui Paulo
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: [CFT] Update to clang 3.4
On 5 Jan 2014, at 05:00, Dimitry Andric d...@freebsd.org wrote: I need some assistance with this, from somebody who knows exactly how CTF and DTrace work together. Our CTF tools use libdwarf in base, which is also quite old, and seems to be largely unmaintained. It does not seem to support anything beyond DWARF2. I think it would be worthwhile to upgrade this library from upstream ASAP. Our libdwarf was a from scratch implementation and we never used the LGPL libdwarf. I don't know if it's worth investing time upgrading our BSD licenced libdwarf or importing the LGPL libdwarf. Given the push to keep the tree mostly BSD licenced, I would say the former. -- Rui Paulo ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: [poc] buildkernel + clang + -Werror
On Nov 6, 2011, at 12:58 PM, Alexander Best wrote: On Sun Nov 6 11, Dimitry Andric wrote: On 2011-11-06 21:33, Alexander Best wrote: ... the problem is, something like uint x; if (x 0) ... clang will warn about this, yet it is 100% valid code so my vote would be to make such an error into a warning. Sorry, but checking something unsigned to be smaller than zero is bogus, or at the least superfluous, and it's perfectly sane to warn about this, especially since the compiler is not going to emit code for it at all. there was a discussion with the topic disable -Wtautological-compare for clang on freebsd-toolchain@ and most of the devs considered this code *not* to be bogus. ;) Tautologic checks are good because they may find problems you never thought about. The examples pointed out are quite simple and are missing the point. You have to thinking about crazy macros. The only argument against this tautological check that I agree with is when the code is explicitly trying to be safe. If the developer checks for i 0 when indexing an array he/she is trying to guard against possible pitfalls in the future when someone suddenly decides to change the variable type to become signed. One possible security vulnerability was avoided because that developer checked for negative values. I'm against turning this off by default, but it should not cause an error. Regards, -- Rui Paulo ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: [poc] buildkernel + clang + -Werror
On Nov 6, 2011, at 4:36 PM, Warner Losh wrote: On Nov 6, 2011, at 2:13 PM, Rui Paulo wrote: The only argument against this tautological check that I agree with is when the code is explicitly trying to be safe. If the developer checks for i 0 when indexing an array he/she is trying to guard against possible pitfalls in the future when someone suddenly decides to change the variable type to become signed. One possible security vulnerability was avoided because that developer checked for negative values. I'm against turning this off by default, but it should not cause an error. Except when you pass args back and forth between signed and unsigned and back again. If you check 0 in the middle, that's one more security bug you thought you had fixed, but really you've done nothing with. Of course, but in the context of the compiler checks this argument doesn't apply. Regards, -- Rui Paulo ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
