Tim Clewlow wrote:
Hi there,
Installing 7.0 via PXE has a slight problem that is easily worked around. The
file /boot/mfsroot.gz on the installation media needs to be unzipped to make
PXE boot via tftp/nfs work. Otherwise the loader ultimately complains that it
cant find the device to boot
Den 04/06/2009 kl. 11.38 skrev Ed Schouten:
You can now build your very own version of FreeBSD with Clang
installed
as /usr/bin/cc as follows:
Thanks for your hard work, Ed. This is great news!
You might want to mention that a few parts are still GCC-compiled due
to bugs in Clang ( see
Hi Roman
Den 04/06/2009 kl. 14.38 skrev Roman Divacky:
you could use llvm-ld (see the wiki for instructions how to do it).
there's also some
effort to make gnu ld usable with llvm LTO and I guess the patch
could be backported
to our ld. I guess
As I understand the reply from Eli
Den 04/06/2009 kl. 18.06 skrev Tim Kientzle:
Erik Cederstrand wrote:
LLVM provides a linker (http://llvm.org/cmds/llvm-ld.html) but it
doesn't interact correctly with conventional nm/ar/etc (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005296.html
).
In what way does
Den 30/05/2010 kl. 14.51 skrev Andrius Morkūnas:
On Sun, 30 May 2010 14:58:05 +0300, Volodymyr Kostyrko c.kw...@gmail.com
wrote:
1. __dso not found after link. Some symbols seems to be omitted from
libraries and linking of plugins fails badly.
Known problem with known fix.
2. Assembler
Den 30/05/2010 kl. 16.15 skrev C. Bergström:
What's the real status of a fully permissive licensed toolchain?
You mean ClangBSD?
1) Benchmarks - (I mean emperical evidence on FBSD and per target with no
anecdotal comments or speculation.. I admit benchmarks can actually be
misleading
Hello hackers,
I got reminded of a problem I had a couple of years back compressing FreeBSD
jails. I was using bsdiff for the compression and found out that md5 sums of
static libraries (.a files) in /usr/lib and /usr/local/lib didn't match between
jails, even though the source code used to
Den 05/10/2010 kl. 15.59 skrev Erik Trulsson:
On Tue, Oct 05, 2010 at 03:28:36PM +0200, Erik Cederstrand wrote:
Hello hackers,
I got reminded of a problem I had a couple of years back compressing
FreeBSD jails. I was using bsdiff for the compression and found out
that md5 sums of static
Den 06/10/2010 kl. 08.00 skrev Tim Kientzle:
That's the timestamp on the pseudo-entry used to store the archive
symbol table. (GNU/SysV ar files use a pseudo-entry named / to
store the symbol table. Since '/' is added to end of names in this
format, this is essentially an entry with an
Den 06/10/2010 kl. 10.06 skrev per...@pluto.rain.com:
Erik Cederstrand e...@cederstrand.dk wrote:
It seems I can at least normalize the .a files using something
like the following to weed out timestamps and uid/gid:
% ar -x /usr/lib/libfetch.a
% chown 0:0 *
% touch -t 19700101
Den 06/10/2010 kl. 08.00 skrev Tim Kientzle:
% diff mod.strings orig.strings
2c2
/ 1286312209 0 0 0 958 `
---
/ 1269146263 0 0 0 958 `
That's the timestamp on the pseudo-entry used to store the archive
symbol table.
Den 06/10/2010 kl. 13.07 skrev Erik Cederstrand:
Is something like the following acceptable? Without risking changes to
buildworld/distribution just now, this would allow me to dump contents of an
archive and re-insert them with '0' for mtime, uid and gid before checking
checksums
Den 06/10/2010 kl. 14.35 skrev Erik Cederstrand:
Den 06/10/2010 kl. 13.07 skrev Erik Cederstrand:
Is something like the following acceptable? Without risking changes to
buildworld/distribution just now, this would allow me to dump contents of an
archive and re-insert them with '0
Hi hackers
As a followup to the Timestamps in static libraries thread which resulted in
a '-D' option to ar(1), I'd like to discuss if it is a worthy goal of the
Project to create deterministic builds. By that I mean for two make
build+install world+kernel+distribution runs, every contained
Den 11/10/2010 kl. 10.47 skrev Kostik Belousov:
My personal opinion that the feature is nice to have. Unless the changes to
get this working are too large, and, more importantly, unless the maintenance
cost of having this in good shape is too high, sure we would better have
deterministic
Den 21/10/2010 kl. 19.57 skrev Ulrich Spörlein:
On Mon, 11.10.2010 at 11:35:42 +0200, Erik Cederstrand wrote:
I'm beginning to think that it should at least be optional. Removing e.g.
build times, mtimes and path to OBJDIR or SRCDIR might not make everyone
happy.
The problem
Den 22/10/2010 kl. 12.01 skrev Ulrich Spörlein:
Why do you make this a requirement? Of course it's usually easier to
build different releases from different source directories, but I think
requiring the following conditions are fine:
1. If you build a specific svn revision,
2. sitting in
Den 12/11/2010 kl. 21.20 skrev Giorgos Keramidas:
Since the SVN rev. is recorded, I think a timestamp is redundant. Any
ideas where I can disable the timestamps in the source?
The timestamp is not 'redundant'. It records _when_ you compiled the
sources of the kernel, which in itself is
Den 14/11/2010 kl. 21.32 skrev Dimitry Andric:
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
Den 15/11/2010 kl. 12.40 skrev Tom Evans:
The important things for us are that given a binary, you should be
able to easily reproduce the source environment that the binary was
produced from, and any two binaries produced from the same sources
should be identical.
I'm leaning towards not
Den 22/10/2010 kl. 12.01 skrev Ulrich Spörlein:
Why do you make this a requirement? Of course it's usually easier to
build different releases from different source directories, but I think
requiring the following conditions are fine:
1. If you build a specific svn revision,
2. sitting in
Hello hackers,
With a simple version of deterministic builds done (see my previous post here -
anyone willing to comment the patch?), I have started to look at the more
general case where OBJDIR and SRCDIR change between builds. The following are
my findings.
Kernel modules:
Den 25/11/2010 kl. 13.08 skrev Erik Cederstrand:
Symbol tables:
For example, libstand.a shows up in a diff. Looking with objdump, I see the
contained _setjmp.o file has the following symbol table:
SYMBOL TABLE:
ldf *ABS*
/usr/home/erik
Den 25/11/2010 kl. 20.17 skrev Mark Johnston:
On Thu, Nov 25, 2010 at 01:08:58PM +0100, Erik Cederstrand wrote:
Kernel modules:
--
In the ELF section .gnu-debuglink, there is a link to the corresponding
*.ko.symbols file. It seems to be an inode or such rather than
Den 25/11/2010 kl. 13.08 skrev Erik Cederstrand:
rodata.str1.4:
--
Some *.o files (all?) contain the path to the corresponding source file:
Contents of section .rodata.str1.4:
2f757372 2f686f6d 652f6572 696b2f66 /usr/home/erik/f
0010 72656562 73642f68 6561642f
Den 02/12/2010 kl. 03.44 skrev Ryan Stone:
Does the C file use the __FILE__ macro?
There are a bit over 1000 files with checksum mismatches, but they seem to
differ in the same way. I've picked an example: /usr/lib/libbsnmp.a
It contains the string
Hi Ryan,
Den 02/12/2010 kl. 05.01 skrev Ryan Stone:
asn1.c uses the assert macro, while I believe uses __FILE__.
Thanks for the help! asn1.c does indeed import src/include/assert.h, which
optionally uses __FILE__ if NDEBUG is not defined. I've tried adding -DNDEBUG
to my CFLAGS, but apart
Hi Joerg,
Den 02/12/2010 kl. 13.49 skrev Joerg Sonnenberger:
On Thu, Dec 02, 2010 at 11:08:09AM +0100, Erik Cederstrand wrote:
I wonder if I could hack __FILE__ to be a path relative to src/. That
would be a way to fix all the source file paths I see.
I have a patch for that in NetBSD's
Den 18/01/2012 kl. 03.21 skrev Devin Teske:
Looking at bin/164192...
I'm left wondering to myself...
How on Earth did a regression-by-typo introduced in SVN r214735 go 14 months
without being noticed?
Because the regression tests in FreeBSD don't cover this part of the code?
:-)
Hi Ali,
Den 17/04/2012 kl. 12.35 skrev ali mousa:
Hi all
I'm working on a new tool that may increase Operating System
performance. I'm looking for a tool that can measure OS performance
especially FreeBSD, so I can compare after and before applying the
patch.
Take a look at the
Den 03/09/2012 kl. 09.25 skrev Junior White efi...@gmail.com:
hi all,
I build a new kernel and install it, but don't known how to test the my
new kernel's performance.
I have read the Regressin and Performance Testing Guide in developer's
handbook. But where is
the test program is, and
Hello hackers,
I'm looking through the Clang Analyzer scans on
http://scan.freebsd.your.org/freebsd-head looking for false positives to report
back to LLVM. There are quite a list of reports suggesting to change vfork()
calls to posix_spawn(). Example from /bin/rpc:
Den 14/09/2012 kl. 13.03 skrev Ivan Voras ivo...@freebsd.org:
On 14/09/2012 09:49, Erik Cederstrand wrote:
Hello hackers,
I'm looking through the Clang Analyzer scans on
http://scan.freebsd.your.org/freebsd-head looking for false positives to
report back to LLVM. There are quite a list
the analyzer reason correctly about the code,
and removes the report mentioned above (and a handful others in ncurses). It
doesn't touch contrib code, but I'm not happy about changing include/assert.h
since it's used so many other places. Any other ideas for how to best solve
this?
Kind regards,
Erik
Den 19/09/2012 kl. 11.19 skrev Erik Cederstrand e...@cederstrand.dk:
The below below patch will let the analyzer reason correctly about the code,
and removes the report mentioned above (and a handful others in ncurses). It
doesn't touch contrib code, but I'm not happy about changing include
Clang Analyzer reports about 100 cases of Allocator sizeof operand mismatch,
for example:
http://scan.freebsd.your.org/freebsd-head/sbin.umount/2012-09-23-amd64/report-k4ThD9.html#EndPath
The reports seem to be valid, but I'm no export. I can work out that the above
should probably be fixed by
Hi list,
I'm looking at this possible divide-by zero in dhclient:
http://scan.freebsd.your.org/freebsd-head/WORLD/2012-10-07-amd64/report-nBhqE2.html.gz#EndPath
In this specific case, it's obvious from the intention of the code that
ip-client-interval is always 0, but it's not obvious to me in
Hello,
I'm looking at some Clang Static Analyzer reports in the kernel, and a lot of
them point back to a null pointer dereference in __pcpu_type
(sys/amd64/include/pcpu.h:102) which is defined as:
102 /*
103 * Evaluates to the type of the per-cpu variable name.
104 */
105
Den 16/10/2012 kl. 12.19 skrev Wojciech A. Koszek wkos...@freebsd.org:
(cross-posted message; please keep discussion on freebsd-hackers@)
Those of you who have Wiki access, please spent 2 more minutes and submit
straight to Wiki:
http://wiki.freebsd.org/GoogleCodeIn/2012Tasks
Hello,
I'm looking at this Clang analyzer report:
http://scan.freebsd.your.org/freebsd-head/WORLD/2012-10-24-amd64/report-uH6BjZ.html.gz#EndPath
Apart from the actual error, which is a apse positive, it seems like Clang
can't find the macro definitions for B_TRUE and B_FALSE (if it did,
Hello Ian,
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,
Den 29/10/2012 kl. 11.30 skrev Dimitry Andric d...@freebsd.org:
On 2012-10-29 09:12, Erik Cederstrand wrote:
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
Den 07/11/2012 kl. 15.35 skrev Nikolay Denev nde...@gmail.com:
Actually MAXBSIZE is 64k, MAXPHYS is 128k.
There was a thread about NFS performance where it was mentioned that bigger
MAXBSIZE leads to KVA fragmentation.
That thread starts here:
Hello hackers,
The following PR patches crunchide(1) to accept object files produced by the
gold and mclinker linkers:
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin%2F174011
On behalf of the submitter, I'd like to request a review of the patch, and
testing of crunchide/crunchgen especially
44 matches
Mail list logo
