Diff below makes the calls to _malloc_init() from inside libc go direct,
while leaving malloc_init() callable from outside for libpthread,
eliminating the overridable PLT entry for _malloc_init.
ok?
With the harsh light of California beating down on me, I now wonder if we
should have instead
On systems that don't have a native version, we use an implementation of
sqrtl() (square-root of long double) that -- to do its job -- pokes at the
floating-point exception state and rounding mode. In particular, at a key
point it clears any previous "inexact" exception and sets the rounding
On Sat, 10 Sep 2016, Philip Guenther wrote:
> Same diff as binutils, with same open question:
>
> > Maybe we should add ${INSTALL_STRIP} to the INSTALL_PROGRAM assignment
> > here?
Here's the combined diff that does that.
(Note to self: if you set DEBUG in /etc/mk.conf, INSTALL_STRIP isn't set)
On Sat, Sep 10, 2016 at 1:42 PM, Philip Guenther wrote:
> On Sat, 10 Sep 2016, Philip Guenther wrote:
>
>> On Sat, 10 Sep 2016, Martin Natano wrote:
>> > Yet another symlink that belongs to root. Ok?
>> ...
>> > --- sbin/sysctl/Makefile4 May 2016 19:48:08 - 1.11
>> > +++ sbin/sysctl/
Same diff as binutils, with same open question:
> Maybe we should add ${INSTALL_STRIP} to the INSTALL_PROGRAM assignment
> here?
ok?
Index: usr.bin/binutils-2.17/Makefile.bsd-wrapper
===
RCS file: /data/src/openbsd/src/gnu/usr.bi
This should fix the ownership (and mode) of /usr/bin/gdb and its
associated info pages.
ok?
One open question: we never strip gdb, unlike other binaries. Maybe we
should add ${INSTALL_STRIP} to the INSTALL_PROGRAM assignment here?
Philip Guenther
Index: usr.bin/binutils/Makefile.bsd-wrappe
On Sat, 10 Sep 2016, Mark Kettenis wrote:
> From: Philip Guenther
...
> > Also interesting that it generates memmove() calls. Wonder where it
> > ended up doing that.
>
> Well, clang actually calls the functions with their standard name even
> for the cases where we explicitly call those funct
> Date: Sat, 10 Sep 2016 13:55:15 -0700
> From: Philip Guenther
>
> On Sat, 10 Sep 2016, Mark Kettenis wrote:
> > Thanks. Now the only issue seems to be:
> >
> > barber$ check_sym
> > /usr/lib/libc.so.89.1 --> obj/libc.so.89.1
> > Dynamic export changes:
> > PLT added:
> > __stack_sma
On Sat, 10 Sep 2016, Martin Natano wrote:
> Another set of symlinks, same drill: the owner should be root. Ok?
...
> --- usr.sbin/mailwrapper/Makefile 16 Mar 2009 22:34:13 - 1.5
> +++ usr.sbin/mailwrapper/Makefile 10 Sep 2016 17:53:45 -
> @@ -13,5 +13,9 @@ afterinstall:
>
On Sat, 10 Sep 2016, Martin Natano wrote:
> Currently the /usr/share/calendar/$lang directories are created with the
> build user as owner, but should be owned by root. Ok?
ok guenther@
On Sat, 10 Sep 2016, Mark Kettenis wrote:
> Thanks. Now the only issue seems to be:
>
> barber$ check_sym
> /usr/lib/libc.so.89.1 --> obj/libc.so.89.1
> Dynamic export changes:
> PLT added:
> __stack_smash_handler
> memcpy
> memmove
> memset
>
> Not sure how to
On Sat, 10 Sep 2016, Martin Natano wrote:
> When building with noperm the symlinks end up with the build user as
> owner instead of root. Ok?
...
> --- bin/chmod/Makefile6 Sep 2001 18:52:55 - 1.7
> +++ bin/chmod/Makefile10 Sep 2016 17:31:05 -
> @@ -10,9 +10,11 @@ LINKS
> Date: Sat, 10 Sep 2016 13:33:58 -0700
> From: Philip Guenther
>
> On Sat, 10 Sep 2016, Mark Kettenis wrote:
> > Seems the clang assembler ignores a .weak directive before the symbol is
> > defined.
> >
> > ok?
>
> certainly.
Thanks. Now the only issue seems to be:
barber$ check_sym
/usr
On Sat, 10 Sep 2016, Philip Guenther wrote:
> On Sat, 10 Sep 2016, Martin Natano wrote:
> > Yet another symlink that belongs to root. Ok?
> ...
> > --- sbin/sysctl/Makefile4 May 2016 19:48:08 - 1.11
> > +++ sbin/sysctl/Makefile10 Sep 2016 18:05:09 -
> > @@ -7,5 +7,6 @@ CPPFLA
On Sat, 10 Sep 2016, Martin Natano wrote:
> Yet another symlink that belongs to root. Ok?
...
> --- sbin/sysctl/Makefile 4 May 2016 19:48:08 - 1.11
> +++ sbin/sysctl/Makefile 10 Sep 2016 18:05:09 -
> @@ -7,5 +7,6 @@ CPPFLAGS+=-D_LIBKVM
>
> afterinstall:
> ln -sf
On Sat, 10 Sep 2016, Mark Kettenis wrote:
> Seems the clang assembler ignores a .weak directive before the symbol is
> defined.
>
> ok?
certainly.
fpclassify(3) says:
The symbols isinff(), and isnanf() are provided as compatibility aliases
to isinf(), and isnan(), respectively, and their uses are deprecated.
Similarly, finite() and finitef() are deprecated versions of isfinite().
So let's use the preferred names in libm.
ok
Seems the clang assembler ignores a .weak directive before the symbol
is defined.
ok?
Index: lib/libc/arch/amd64/sys/brk.S
===
RCS file: /cvs/src/lib/libc/arch/amd64/sys/brk.S,v
retrieving revision 1.8
diff -u -p -r1.8 brk.S
--- lib
Another diff I typoed, also found by rpe@. Ok?
Index: share/misc/pcvtfonts/Makefile
===
RCS file: /cvs/src/share/misc/pcvtfonts/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- share/misc/pcvtfonts/Makefile 13 Ma
I used chmod instead of chown. That's what I get for changing the diff
_after_ testing it... Mistake found by rpe@, thanks!
Fixed diff below. Ok?
Index: etc/Makefile
===
RCS file: /cvs/src/etc/Makefile,v
retrieving revision 1.430
di
> Date: Sat, 10 Sep 2016 11:59:29 -0700
> From: Philip Guenther
>
> The functions here all have full prototypes in scope, so gcc is already
> treating them as if they were standard-style definitions. While here,
> s/__inline/inline/ as it's been 17 years since C99.
>
> ok?
ok kettenis@
> A
Maybe we should just not install it? Mark?
On Sat, Sep 10, 2016 at 07:47:30PM +0200, Martin Natano wrote:
> We should be explicit about owner/group when using install, so this also
> works correctly with noperm. Ok?
>
> natano
>
>
> Index: usr.bin/mg/Makefile
> =
The functions here all have full prototypes in scope, so gcc is already
treating them as if they were standard-style definitions. While here,
s/__inline/inline/ as it's been 17 years since C99.
ok?
A warning for those doing these sorts of K&R -> standard conversions:
beware of argument orde
Diff below sets the owner for the /etc/localtime, /etc/rmt, /var/tmp
and /sys symlinks and for the /var/sysmerge/etc.tgz tarball.
This is the last of the noperm related pending M's in my tree.
Ok?
natano
Index: etc/Makefile
===
RC
> Date: Sat, 10 Sep 2016 11:14:53 -0700
> From: Philip Guenther
>
> On Sat, 10 Sep 2016, Mark Kettenis wrote:
> > ok kettenis@, but it is probably time to rewrite the comment above
> > thie function as well.
>
> Like this?
Yeah, nothing worth keeping in the bits you removed.
> Index: trap.c
>
A couple of ownership fixes for share/. While there I cleaned up the
pcvtfonts install loop. Ok?
natano
Index: share/misc/pcvtfonts/Makefile
===
RCS file: /cvs/src/share/misc/pcvtfonts/Makefile,v
retrieving revision 1.6
diff -u -p -
On Sat, 10 Sep 2016, Mark Kettenis wrote:
> ok kettenis@, but it is probably time to rewrite the comment above
> thie function as well.
Like this?
Index: trap.c
===
RCS file: /cvs/src/sys/arch/sparc64/sparc64/trap.c,v
retrieving revi
Yet another symlink that belongs to root. Ok?
natano
Index: sbin/sysctl/Makefile
===
RCS file: /cvs/src/sbin/sysctl/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- sbin/sysctl/Makefile4 May 2016 19:48:08 -
Another set of symlinks, same drill: the owner should be root. Ok?
natano
Index: usr.sbin/mailwrapper/Makefile
===
RCS file: /cvs/src/usr.sbin/mailwrapper/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- usr.sbin/mai
We should be explicit about owner/group when using install, so this also
works correctly with noperm. Ok?
natano
Index: usr.bin/mg/Makefile
===
RCS file: /cvs/src/usr.bin/mg/Makefile,v
retrieving revision 1.31
diff -u -p -r1.31 Make
Currently the /usr/share/calendar/$lang directories are created with the
build user as owner, but should be owned by root. Ok?
natano
Index: usr.bin/calendar/Makefile
===
RCS file: /cvs/src/usr.bin/calendar/Makefile,v
retrieving rev
When building with noperm the symlinks end up with the build user as
owner instead of root. Ok?
natano
Index: bin/chmod/Makefile
===
RCS file: /cvs/src/bin/chmod/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- bin/c
I'm not an OpenBSD user, I'm not asking for help. I'm posting here
because OpenBSD was the only mention of this device I found when
searching the net. My device also identifies as 0x4651 0x3273, though
marked as PCI 60806 instead of TX382B. I never found a data sheet for
it, but after some trial an
> Date: Fri, 9 Sep 2016 20:44:00 -0700
> From: Philip Guenther
>
> On Fri, 9 Sep 2016, Philip Guenther wrote:
> > Noticed while looking at Jasper's diff.
> > - convert declarations from k&r to standard C
> > - delete support for 32bit frame backtracing. I doubt this code has ever
> >been
> Date: Fri, 9 Sep 2016 20:47:47 -0700
> From: Philip Guenther
>
> Simplify syscall():
> - if the trapframe is of a 32bit process, just call sigexit() instead of
>returning an error
> - delete other code for 32bit processes
> - 64bit processes only, so SYS__syscall can be handled the same
> Isn't the solution to this problem a working dynamic buffer cache? I'm
> not sure adding a hack for mfs, and the complexity that comes with it,
> is the way to go. Did somebody analyzed what broke when the buffer
> cache was cranked to 90%?
My digging suggested that something on "write side" g
> On Thu, Sep 08, 2016 at 07:47:58PM -0400, Daniel Micay wrote:
>
> > A nice security property of 0xdf filling is that a use-after-free of a
> > pointer is guaranteed to fault in a typical environment since it ends up
> > pointing outside userspace (I assume that's the case on OpenBSD). A heap
> >
My system don't started Tor daemon and dnscrypt-proxy
daemon and still I get this kernel panic.
I still use Unbound.
I still have pf rules for transparent
proxying. I only disabled Tor client.
I was thinking about simplify more before I answer, but
dhill () mindcry ! org posted similar bug to bug
This removes unnecessary fluff from the AUX STA code and simplifies error
handling around iwm_send_cmd_pdu_status() calls. While at it I spotted an
uninitalized 'status' variable in iwm_add_int_sta_common() (note how
iwm_send_cmd_pdu_status() won't always initialize *status).
Index: if_iwm.c
=
Pending NFS requests loop forever, blocking umount and not even allowing
for clean shutdown/reboot.
If you ever played with NFS for more than 30 seconds, you have run into
this and had to press the reset button, followed by suffering through
fsck...
Pending requests occur because the NFS server i
On Thu, Sep 08, 2016 at 07:47:58PM -0400, Daniel Micay wrote:
> A nice security property of 0xdf filling is that a use-after-free of a
> pointer is guaranteed to fault in a typical environment since it ends up
> pointing outside userspace (I assume that's the case on OpenBSD). A heap
> spray could
41 matches
Mail list logo
