Friday, February 11, 2011
Wednesday, December 08, 2010
bin/44188: gcov sucks
Nice bug report:
>Number: 44188
>Category: bin
>Synopsis: gcov sucks
>Confidential: no
>Severity: critical
>Priority: low
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Dec 03 08:00:00 +0000 2010
>Originator: David A. Holland
>Release: NetBSD 5.99.41 (20101130)
>Organization:
>Environment:
System: NetBSD tanaqui 5.99.41 NetBSD 5.99.41 (TANAQUI) #32: Wed Dec 1 01:20:02 EST 2010 dholland@tanaqui:/usr/src/sys/arch/i386/compile/TANAQUI i386
Architecture: i386
Machine: i386
>Description:
gcov is primitive and really painful to use for trying to handle coverage of a real project.
The really serious problem is that there's no way to tell gcov that certain lines of code are expected to not be reached. Any real project has some and perhaps many of these, whether they're genuinely meant to be unreached (e.g. lines that contain "assert(0)") or they're currently unreached because of limitations in your test apparatus and you want to shut gcov up about them so you can concentrate on the stuff that's tractable.
It also only has rudimentary support for coping with basic blocks that are less than a full line of code. This often arises with expressions that contain && and ||... particularly assert expressions... and using this support makes the preceding problem markedly worse. This problem also arises if you have large macros; the invocation of the macro functions as one line with perhaps many basic blocks.
Other problems and annoyances include:
- It does not seem to be able to cope with inline functions at all;
the counts always come out zero.
- Running a gcov-enabled binary makes a mess because it leaves
dump files in your source tree.
- Then, to run gcov you have to then hunt all these dump files
down, and when you do it rewards you by leaving more files in
your source tree.
- The logging code in gcov-enabled programs is apparently not
multiprocessor-safe; if you run your test suite in parallel it
spews warnings and the output files apparently get corrupted.
(I hate to think what happens if you try to use gcov with a
multithreaded program.)
- gcov itself spams the tty when it runs; the information it prints
is not particularly useful to have on the tty.
>How-To-Repeat:
Try working with gcov on a project that's being actively developed.
>Fix:
Someone(tm) should write new coverage tools.
Monday, October 25, 2010
use autodie;
I rarely use perl but I'm sure I'll need this feature next time I dive into perl ;-)
-----Original Message----- From: owner-tech@openbsd.org [mailto:owner-tech@openbsd.org] On Behalf Of Marc Espie Sent: 04 October 2010 13:24 To: tech@openbsd.org Subject: new perl if you run into "fishy" perl scripts, newer perl includes (as standard) autodie. a simple use autodie; and at least, stupid stuff that NEVER CHECKS error returns from open() and the like will die, die, die instead of struggling onwards...
Wednesday, November 04, 2009
Tuesday, November 03, 2009
LuaJIT 2.0.0-beta1
New version of LuaJIT is very impressive. Take a deep breath ...
Mike Pall wrote: > As I've already said in a reddit comment: > > Heh, it beats Intel Fortran on two numeric benchmarks (mandelbrot > and spectralnorm). > > Only the hand-vectorized stuff in C and C++ is faster. Guess I > need to add auto-vectorization. Well, maybe next week ... > > --Mike
More technical details are available in Mike's message LuaJIT 2.0 intellectual property disclosure and research opportunities.
Saturday, October 10, 2009
mmap'ing to address 0x0
Date: Fri, 09 Oct 2009 22:01:07 -0600
From: Theo de Raadt <deraadt@cvs.openbsd.org>
To: Luis Useche <useche@gmail.com>
cc: misc <misc@openbsd.org>
Subject: Re: mmap'ing to address 0x0
> I was reading some information that indicated that letting user
> process to map to address 0x0 can exploit some kernel NULL-pointer
> bugs. I checked how different operating systems mitigate this problem
> and I found information about Linux and FreeBSD. I was trying to find
> the same information for OpenBSD with no luck. Can anybody help me
> with this one?
We have been aware of the particular problem (which results from an
architectural decision made by some machines) for many years, and it
took us a long time to decide what to do. Eventually we decided to
make userland suffer. Unfortunately we only fixed it in the middle of
last year.
Other platforms do not have this problem, since the kernel runs in
an un-shared address space.
CVSROOT: /cvs
Module name: src
Changes by: deraadt@cvs.openbsd.org 2008/06/24 15:24:03
Modified files:
sys/arch/alpha/include: vmparam.h
sys/arch/amd64/include: vmparam.h
sys/arch/arm/include: vmparam.h
sys/arch/i386/include: vmparam.h
sys/arch/sh/include: vmparam.h
sys/arch/sparc/include: vmparam.h
sys/arch/vax/include: vmparam.h
sys/arch/sh/sh : trap.c
Log message:
On user/kernel shared page table machines, do not let processes map their
own page 0, as discussed with miod (and many others previously, including
art and toby). On sparc, make this __LDPGSZ because PAGE_SIZE is non-constant
ok miod tedu
Wednesday, October 07, 2009
Hello World from Lua
The lua program below prints 'Hello World from Lua'. Enjoy!
_={_=_G
}for--[[--]]__
in(next),_["_"]do
(_)[_]=(__)_[#_[_]]
=_[_]_[_]="sub"end(_)
[_]=_[_] [_[_]]_[_._]=#"_._"_[
_[_._]]=_[_](_[_[_._]*_ [_._]],_[_._],_[_._
]).._[_](_[(_[_._]+_[_._]/_[_._ ])*_[_._]],_[_._]/
_[_._]+_[_._]/_[_._],_[_._]).._[_](_[_ [_._]*_[_._]],_
[_._]+_[_._]-_[_._]/_[_._],_[_._]+_[_._]-_[ _._]/_[_._]
).._[_](_[_[_._]*_[_._]],_[_._],_[_._]).._[_](_[ _
[_._]*_[_._]],_[_._]/_[_._]-_[_._] ,_[_._
]/_[_._]-_[_._])_[_[_._]*_[_._]+_ [_._]-
_[_._]/_[_._]]=(_)_[_[_._]*_[_._]+ _[_._
]+_[_._]/_[_._]]=(_)_[#_+_[_._]/_[ _._]]
=_._[_[#_-_[_._]-#_/#_]]_[_[#_]]=_[ #_](_[
_[_._]].."(".._[#_-#_/_[_._]].."('" .._[_[_
._]]..[[("\\'..(...+#_*(_[_._]+_[_._] ))..'")')
)()]])_[_[#_]]=_[_[_._]][_[_[#_]](_[_. _]*_[_._])
.._[_[#_]](#_-_[_._]/_[_._]).._[_[#_]](_ [_._]+_[_._]
+_[_._]/_[_._]).._[_[#_]](_[_._]^_[_._]-_[_ ._])]_[_[_[#_]](
#_)]=#_*#_/_[_._]_[_[_[#_]](#_)]=_[_[_[#_]](#_)]+_[_[_[#_]](#_)]/_[(
_._)]_._[_[ _[#_]](_[_[_[#_]](#_)]+#_-_[_._],_[_[_[#_]](#_)]+#_-
#_/#_,_[_[_[ #_]](#_)]+#_/_[_._],_[_[_[#_]](#_)]+#_-#_/_[_._], _[
_[_[#_]](#_) ]+#_+#_/#_)](_[_[#_+_[_._]-_[_._]]](#_*#_/_[_._]-_[_.
_],_[_[_[#_] ](#_)]+_[_._] /_[_. _],_[ _ [_[#_]](#_)]+#_
/_[_._]+_[_. _],_[_[_[#_]]( #_)]+ #_/ _[_. _]+_[_._],_[_[
_[#_]](#_)] +#_-_[_._]-_[_ ._]/_ [_._ ],#_ +#_+_[_._]-_[
_._]/_[_._] ,#_*(_[_._]+_[ _._]) -_[_. _ ],_[_[_[#_]](
#_)]+#_-_[ _._]-_[_._ ]/_ [_._] ,_[_ [_[ #_]](#_)]+#_
-#_/#_,_[ _[_[#_]]( #_) ]+#_/ _[_ ._]+ _[_._],_[_[
_[#_]]( #_)],# _+#_ +# _ /# _ + #_/#_,_[_
[_[#_ ]](#_) ]+_ [_._ ]-_ [_._]/_[_
._],_[_[_[#_]](#_)]+#_-_[_._]/_[_._],(_[_._])^_[_._]*(_[
_._]+_[_._]/_[_._])+_[_._],_[_[_[#_]](#_)]+_[_._]*_[_
._],#_+#_+#_/#_+#_/#_,#_*#_/_[_._]+_[_[_[#_]](#_)]/
_[_[_[#_]](#_)],_[_[_[#_]](#_)]+#_+_[_[_[#_]](
#_)]/_[_[_[#_]](#_)]+_[_[_[#_]](#_)]/_[_[
_[#_]](#_)],_[_[_[#_]](#_)]-_[_._]))
_._=_[_[_._]][_[_[_[#_]](#_)]
]_[(#_)^#_-(#_)-#_]=
_._
Code from http://codepad.org/cmQIjdzI.
Friday, September 18, 2009
pkgsrc/lang/gcc44
We've been waiting for update for a long time, the previous version in pkgsrc is lang/gcc34 (wip/gcc42 doesn't count ;-)
Module Name: pkgsrc
Committed By: dmcmahill
Date: Fri Sep 18 11:24:50 UTC 2009
Update of /cvsroot/pkgsrc/lang/gcc44
In directory ivanova.netbsd.org:/tmp/cvs-serv5730
Log Message:
Import gcc-4.4.1 as lang/gcc44. This is the latest branch of gcc.
Of particular note is this package contains gfortran which is required
for building some scientific software (recent versions of scilab
for example). Package is prepared as a monolithic install of gcc
since gcc is really not set up to build and install the core and then
later add on different languages as their own packages.
Status:
Vendor Tag: TNF
Release Tags: pkgsrc-base
N pkgsrc/lang/gcc44/buildlink3.mk
N pkgsrc/lang/gcc44/Makefile
N pkgsrc/lang/gcc44/DESCR
N pkgsrc/lang/gcc44/MESSAGE
N pkgsrc/lang/gcc44/preconfigure.mk
N pkgsrc/lang/gcc44/distinfo
N pkgsrc/lang/gcc44/patches/patch-ad
N pkgsrc/lang/gcc44/patches/patch-aa
N pkgsrc/lang/gcc44/patches/patch-ab
N pkgsrc/lang/gcc44/patches/patch-ae
N pkgsrc/lang/gcc44/patches/patch-ac
N pkgsrc/lang/gcc44/files/i386-dragonfly64.h
N pkgsrc/lang/gcc44/files/dragonfly-spec.h
N pkgsrc/lang/gcc44/files/dragonfly.h
N pkgsrc/lang/gcc44/files/i386-dragonfly.h
N pkgsrc/lang/gcc44/files/hello.f
N pkgsrc/lang/gcc44/files/hello.m
No conflicts created by this import
Wednesday, September 16, 2009
Multiline comments in shell with here-document
Did you know that you can use multiple lines in shell with the ":" command and a here-document? The following example is inspired by two scripts from SHELLdorado:
: <<! if ! file .; then wc `echo *`; fi ! df | tail wc $(echo *) !If '<<!' doesn't work, you can switch to '<<SOMETHING_UNIQUE'.
Tuesday, September 15, 2009
ZFS in FreeBSD
Author: pjd
Date: Tue Sep 15 11:34:53 2009
New Revision: 197218
URL: http://svn.freebsd.org/changeset/base/197218
Log:
We believe ZFS is ready for production use. Remove a warning about it being
experimental. :)
Modified:
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
==============================================================================
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c Tue Sep 15
+11:23:59 2009 (r197217)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c Tue Sep 15
+11:34:53 2009 (r197218)
@@ -3072,8 +3072,6 @@ zfs_modevent(module_t mod, int type, voi
switch (type) {
case MOD_LOAD:
zfs_root_token = root_mount_hold("ZFS");
- printf("WARNING: ZFS is considered to be an experimental "
- "feature in FreeBSD.\n");
mutex_init(&zfs_share_lock, NULL, MUTEX_DEFAULT, NULL);
Subscribe to:
Posts (Atom)