On Mon, Apr 23, 2012 at 06:26:25PM -0400, Christos Zoulas wrote:
> | Yeah but is it going to turn out to e.g. be signed if building on some
> | random broken host OS?
>
> I don't think it will work at all if it is not a 64 bit quantity, will it?
I guess the qeustion is: does the tools build g
On Apr 23, 9:05pm, dholland-sourcechan...@netbsd.org (David Holland) wrote:
-- Subject: Re: CVS commit: src/usr.sbin/makefs/ffs
| On Mon, Apr 23, 2012 at 05:04:45PM -0400, Christos Zoulas wrote:
| > | I was wondering if maybe ino_t isn't reliable for tools...
| >
| > Looks like it is there on
On Mon, Apr 23, 2012 at 05:04:45PM -0400, Christos Zoulas wrote:
> | I was wondering if maybe ino_t isn't reliable for tools...
>
> Looks like it is there on:
> /usr/src/usr.sbin/makefs/ffs/ufs_inode.h: ino_t i_number;
>/* The identity of the inode. */
>
> so it sho
On Apr 23, 8:13pm, dholland-sourcechan...@netbsd.org (David Holland) wrote:
-- Subject: Re: CVS commit: src/usr.sbin/makefs/ffs
| I was wondering if maybe ino_t isn't reliable for tools...
Looks like it is there on:
/usr/src/usr.sbin/makefs/ffs/ufs_inode.h: ino_t i_number;
On Fri, Apr 20, 2012 at 01:23:29PM +, Christos Zoulas wrote:
> >Module Name:src
> >Committed By: dholland
> >Date: Thu Apr 19 19:48:15 UTC 2012
> >
> >Modified Files:
> >src/usr.sbin/makefs/ffs: mkfs.c
> >
> >Log Message:
> >Fix build failure reported by
On Fri, Apr 20, 2012 at 09:52:42AM +0200, Manuel Bouyer wrote:
> > (Furthermore, scsipi is itself wrong. It is a core component; it
> > should be MPSAFE.)
>
> I also agree. So should be ata, if_ethersubr, etc ...
> that's a lot of work.
Yup. Anyone want to make a list of such entities so we
On Mon, 23 Apr 2012 19:02:04 +0100, David Laight wrote:
On Mon, Apr 23, 2012 at 10:09:09AM +0200, Jean-Yves Migeon wrote:
>
> But, as has been pointed out before, code in libc will generate
> alignment traps - because it is faster that way.
I did not know -- care to give an example? #AC excepti
On Mon, Apr 23, 2012 at 10:09:09AM +0200, Jean-Yves Migeon wrote:
> >
> > But, as has been pointed out before, code in libc will generate
> > alignment traps - because it is faster that way.
>
> I did not know -- care to give an example? #AC exception from amd64 was
> not working, so I would gues
On Apr 23, 3:25pm, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/tests/lib/libc/gen
| On Mon, Apr 23, 2012 at 09:05:25AM -0400, Christos Zoulas wrote:
| > Keep reading and then it is the following table:
|
| *sigh*
|
| And then:
|
|For some implementations, th
On Mon, Apr 23, 2012 at 09:05:25AM -0400, Christos Zoulas wrote:
> Keep reading and then it is the following table:
*sigh*
And then:
For some implementations, the value of si_addr may be inaccurate.
Can we just bail and use that as an excuse?
The value on amd64 seems to be completely unrelat
On Apr 23, 9:48am, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/tests/lib/libc/gen
| On Sun, Apr 22, 2012 at 08:25:11PM +, Christos Zoulas wrote:
| > There is no portable way to do this; sigbus according to ToG does not
| > define what si_addr contains.
|
| I r
On Mon, Apr 23, 2012 at 10:13:09AM +0200, Jean-Yves Migeon wrote:
> Careful here; Some Other Operating Systems report data address fault
> with si_addr + SIGBUS, not instruction fault.
Maybe, but we need to define what NetBSD should do and test for that.
I have not checked what NetBSD/amd64 does
Le 23/04/12 09:48, Martin Husemann a écrit :
On Sun, Apr 22, 2012 at 08:25:11PM +, Christos Zoulas wrote:
There is no portable way to do this; sigbus according to ToG does not
define what si_addr contains.
I read it differently:
The header shall define the siginfo_t type as a structure,
Le 22/04/12 18:38, David Laight a écrit :
> On Sun, Apr 22, 2012 at 02:22:30PM +0100, Jean-Yves Migeon wrote:
>>
>> Hmm, siginfo(2) states the following:
>>
>> For SIGBUS and SIGSEGV the siginfo structure contains the
>> following additional members:
>>
>> void *si_addr;
>>
On Sun, Apr 22, 2012 at 08:25:11PM +, Christos Zoulas wrote:
> There is no portable way to do this; sigbus according to ToG does not
> define what si_addr contains.
I read it differently:
The header shall define the siginfo_t type as a structure,
which shall include at least the following me
15 matches
Mail list logo
