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 on
Den 07/11/2012 kl. 15.35 skrev Nikolay Denev :
> 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:
http://lists.freebsd.org/pipermail/freebsd-arch/2010-April
Den 29/10/2012 kl. 11.30 skrev Dimitry Andric :
> 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
Hello Ian,
Den 29/10/2012 kl. 00.24 skrev Ian Lepore :
> 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 b
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, hoverin
Den 16/10/2012 kl. 12.19 skrev Wojciech A. Koszek :
> (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
There are lots of
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 #d
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
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 b
Den 19/09/2012 kl. 11.19 skrev Erik Cederstrand :
> 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 changi
;s used so many other places. Any other ideas for how to best solve
this?
Kind regards,
Erik Cederstrand
Index: lib/ncurses/ncurses/ncurses_cfg.h
===
--- lib/ncurses/ncurses/ncurses_cfg.h (revision 240638)
+++ lib/ncurses/ncurses/
Den 14/09/2012 kl. 13.03 skrev Ivan Voras :
> 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 b
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:
http://scan.freebsd.your.or
Den 03/09/2012 kl. 09.25 skrev Junior White :
> 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 how do i in
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 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?
:-)
Eri
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 hav
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 f
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
"/usr/home/erik/freebsd/head1/src/lib/libb
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
> 0
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
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*
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 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. sitt
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 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
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 it
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. sittin
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 ev
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
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 f
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 an
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 ch
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
Den 06/10/2010 kl. 10.06 skrev per...@pluto.rain.com:
> Erik Cederstrand 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 *
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 wit
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
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 cre
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
Den 30/05/2010 kl. 14.51 skrev Andrius Morkūnas:
> On Sun, 30 May 2010 14:58:05 +0300, Volodymyr Kostyrko
> 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 errors.
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
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 Friedman
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 ht
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 from.
44 matches
Mail list logo
