Re: Can't use gcc in a clang built world
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. Andrew -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 ___ 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
Wide character types
I've been working on getting the ARM EABI working with FreeBSD. As part of the EABI spec the Procedure Call Standard for the ARM Architecture (AAPCS) defines wchar_t as either an unsigned int or an unsigned short with the former as the preferred type. FreeBSD defines wchar_t as a __wchar_t, which is defined as a __ct_rune_t, which is defined as an int. wint_t and rune_t are also defined in terms of __ct_rune_t. wint_t must be a signed type as it needs to hols a WEOF which is defined as -1. The type of rune_t appears to need to be the same as wint_t as the tow* and isw* functions are defined as taking a wint_t by the documentation but __ct_rune_t in the code and compare this value against __rune_t values. My question is am I correct in thinking rune_t and wint_t should be defined as __ct_rune_t with __ct_rune_t defined as an int while wchar_t should be defined as an unsigned int in ARM EABI and defined as an int elsewhere? Andrew ___ 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: How does loader(8) decide where to load the kernel?
On Mon, 7 May 2012 22:32:10 -0700 Tim Kientzle kient...@freebsd.org wrote: On May 7, 2012, at 6:57 AM, John Baldwin wrote: On Saturday, May 05, 2012 1:06:13 am Tim Kientzle wrote: I have ubldr loading the ELF kernel on BeagleBone and am now trying to untangle some of the hacks I used to get this working. Unfortunately, there's one area of the common loader(8) code that I really don't understand: How does sys/boot/common/load_elf.c determine the physical address at which to load the kernel? __elfN(loadfile) has the following comment: [The file] will be stored at (dest). But that's not really true. For starters, loadfile maps dest through archsw.arch_loadaddr. (This mechanism seems to only be used on ia64 and pc98, though the result is later discarded on those platforms.) Loadfile then passes the value to loadimage which does very strange things: On i386, amd64, powerpc, and arm, loadimage subtracts the dest value from the address declared in the actual ELF headers so that the kernel always gets loaded into low memory. (there's some intermediate bit-twiddling I'm glossing over, but this is the general idea). The bit twiddling is supposed to be the equivalent of subtracting KERNBASE from the load address. On both i386 and amd64, there is a direct mapping of the kernel text such that KERNBASE maps address 0, etc. By default on i386 KERNBASE is 0xc000. Exactly my problem. This all assumes that you're loading the kernel into low memory. On the AM3358, the DRAM starts at 0x8000 on boot, so I'm trying to find a clean way to convince the loader's ELF code to put the kernel there. I have a script at [1] that builds an image to load the kernel directly from U-Boot. It figures out where to tell U-Boot to load a kernel by using readelf to find the value of physaddr and kernbase to use to calculate what physical addresses to use to load the kernel to and where the first instruction to execute is. Andrew [1] http://fubar.geek.nz/files/freebsd/omap/build_beagle.sh ___ 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: Unsigned wchar_t
On Sun, 27 Mar 2011 22:07:30 +0200 Stefan Farfeleder ste...@fafoe.narf.at wrote: On Mon, Mar 28, 2011 at 08:36:57AM +1300, Andrew Turner wrote: Along with this WCHAR_MIN and WCHAR_MAX are defined both in wchar.h and machine/_stdint.h. I would like to remove the copy from wchar.h and add an include to machine/_stdint.h. Would there be any problems with either of these or is there a better place to put the __wchar_t typedef and define WCHAR_MIN and WCHAR_MAX? The C standard specifies that both wchar.h and stdint.h shall define WCHAR_MIN and WCHAR_MAX. You cannot simply include machine/_stdint.h from wchar.h because the former contains a lot of other macros. I thought that might be the case. I could create machine/_wchar.h for the defines unless there is a better place for them. Andrew ___ 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
Unsigned wchar_t
Hello hackers@ I'm working on getting FreeBSD working with the ARM EABI. As part of this the Procedure Call Standard for the ARM Architecture (AAPCS) defines wchar_t as an unsigned int. Looking at sys/sys/_types.h rune_t, wchar_t and wint_t are of type __ct_rune_t which is an int. Furthermore as per the comment above the typedef rune_t must be signed to hold EOF of -1 and wchar_t must be the same type as rune_t. Because wchar_t is defined as an unsigned int would there be any issues with moving the typedef for __wchar_t to machine/_types.h and changing it from __ct_rune_t to int with the exception of the ARM EABI case? Along with this WCHAR_MIN and WCHAR_MAX are defined both in wchar.h and machine/_stdint.h. I would like to remove the copy from wchar.h and add an include to machine/_stdint.h. Would there be any problems with either of these or is there a better place to put the __wchar_t typedef and define WCHAR_MIN and WCHAR_MAX? Andrew ___ 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: Using shell commands versus C equivalents
On Sat, 16 Jun 2007 21:53:06 -0700 Tim Kientzle [EMAIL PROTECTED] wrote: Also, were the bottlenecks seen in pkg_delete and pkg_add, or does it appear to be distributed across the board? The biggest time sink in pkg_add is writing each file to a temp dir then copying it to its final location. There are a couple of strategies for avoiding this (by writing the files directly to their final location), but it basically requires rewriting pkg_add from scratch. I prototyped this a long time ago and found about a 3x speedup. (Parts of that prototype eventually became libarchive.) I've also seen a 3x speedup by using my reimplementation of pkg_add using my package management library, libpkg (http://libpkg.berlios.de). It is not production ready yet as if it fails partway through an installation it won't clean up and installed files. I haven't looked closely at pkg_delete, but I doubt there's much that can be done to speed it up; once you've examined the dependency information to determine what can be deleted, actually removing the files is a pretty straightforward operation. I ran a quick test on installing and removing a single package with both the cvs and my own version of pkg_delete. I got a small but significant speed improvement with my implementation. The difference was too small to be noticeable by a human though (from 0.11s to 0.07s). Andrew -- Andrew Turner http://fubar.geek.nz/blog/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using shell commands versus C equivalents
On Sun, 17 Jun 2007 09:27:32 -0700
Garrett Cooper [EMAIL PROTECTED] wrote:
Your source looks very nice, but there are a few comments:
1. How do you read BDB stuff without including the BDB headers/libs?
I don't. I've only implemented enough to reimplement
pkg_{add,delete,info}. None of these need BDB.
2. I can't go and graft your libs, or do something similar with the
current source because I don't want to break production code
(pkg_install) of this importance and muck up a lot of user's systems
irrevocably.
I know. To use libpkg in the base would require the rest of the pkg
tools to be implemented and a lot of testing. As I haven't implemented
all the base pkg tools and testing has just been with a limited number
of packages I wouldn't want to be responsible for the breakage using
libpkg causes.
Andrew
--
Andrew Turner
http://fubar.geek.nz/blog/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
