On 24.02.2020 20:32, Christos Zoulas wrote:
> In article <20200221222550.325a6f...@cvs.netbsd.org>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:kamil
>> Date:Fri Feb 21 22:25:50 UTC 2020
>>
>> Modified Files:
>> src/tests/lib/libc/ge
In article <20200221222550.325a6f...@cvs.netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Fri Feb 21 22:25:50 UTC 2020
>
>Modified Files:
> src/tests/lib/libc/gen: t_siginfo.c
>
>Log Message:
>Mark division by 0 as expected in sigf
On 24.02.2020 20:29, Christos Zoulas wrote:
> In article <20200222191457.87687f...@cvs.netbsd.org>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:kamil
>> Date:Sat Feb 22 19:14:57 UTC 2020
>>
>> Modified Files:
>> src/tests/lib/libc/ge
In article <20200222191457.87687f...@cvs.netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Sat Feb 22 19:14:57 UTC 2020
>
>Modified Files:
> src/tests/lib/libc/gen: Makefile
>
>Log Message:
>Update t_siginfo.c build rules
>
>Add log
On 21.02.2020 23:53, matthew green wrote:
>> Disable ubsan instrumentation on the operation.
>
> +#if defined(__clang__)
> +__attribute__((no_sanitize("undefined")))
> +#else
> +__attribute__((no_sanitize_undefined))
> +#endif
>
> can we get a __disable_sanitizer or something i cdefs.h?
>
>
> .
> Disable ubsan instrumentation on the operation.
+#if defined(__clang__)
+__attribute__((no_sanitize("undefined")))
+#else
+__attribute__((no_sanitize_undefined))
+#endif
can we get a __disable_sanitizer or something i cdefs.h?
.mrg.
On Oct 14, 12:31am, jus...@specialbusservice.com (Justin Cormack) wrote:
-- Subject: Re: CVS commit: src/tests/lib/libc/gen
| Well also there is the bit thats says
|
|
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13_01
|
| When pattern matching is used where
On Mon, Oct 13, 2014 at 2:26 PM, Christos Zoulas wrote:
> On Oct 13, 2:23pm, jus...@specialbusservice.com (Justin Cormack) wrote:
> -- Subject: Re: CVS commit: src/tests/lib/libc/gen
>
> | You can have a ] by having it as the first character that is made explicit.
> | And if the /
On Oct 13, 2014 2:13 PM, "Christos Zoulas" wrote:
>
> On Oct 13, 11:29am, jus...@specialbusservice.com (Justin Cormack) wrote:
> -- Subject: Re: CVS commit: src/tests/lib/libc/gen
>
> | Not sure about this. See
> |
http://pubs.opengroup.org/onlinepubs/009695
On Oct 13, 2:23pm, jus...@specialbusservice.com (Justin Cormack) wrote:
-- Subject: Re: CVS commit: src/tests/lib/libc/gen
| You can have a ] by having it as the first character that is made explicit.
| And if the / is not special then that is no problem either.
Yes, '/' is the probl
On Oct 13, 11:29am, jus...@specialbusservice.com (Justin Cormack) wrote:
-- Subject: Re: CVS commit: src/tests/lib/libc/gen
| Not sure about this. See
|
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html#tag_09_03_05
|
| "The special characters '.'
On Sun, Oct 12, 2014 at 11:33 PM, Christos Zoulas wrote:
> Module Name:src
> Committed By: christos
> Date: Sun Oct 12 22:33:41 UTC 2014
>
> Modified Files:
> src/tests/lib/libc/gen: t_fnmatch.c
>
> Log Message:
> You need double the number of backslashes in a pattern, sinc
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 implementati
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.
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
In article <20120422085226.787f717...@cvs.netbsd.org>,
Martin Husemann wrote:
>Module Name: src
>Committed By: martin
>Date: Sun Apr 22 08:52:26 UTC 2012
>
>Modified Files:
> src/tests/lib/libc/gen: t_siginfo.c
>
>Log Message:
>Do not compare si_addr (address of faulting instruct
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;
>int si_trap;
>
> si_addr contains the a
On Sun, 22 Apr 2012 08:52:26 +, Martin Husemann wrote:
Module Name:src
Committed By: martin
Date: Sun Apr 22 08:52:26 UTC 2012
Modified Files:
src/tests/lib/libc/gen: t_siginfo.c
Log Message:
Do not compare si_addr (address of faulting instruction) against the
unalig
Le 21/04/12 19:47, Christoph Egger a écrit :
>> rip 0x0 and rsp 0x50202 look really abnormal to me. I'll have a look in
>> FreeBSD, that's probably a group of exceptions that have to be handled
>> differently.
>
> rip 0x0 often means that a function pointer has been called which is
NULL.
>
> Chr
On 21.04.12 19:38, Jean-Yves Migeon wrote:
> Le 21/04/12 16:31, Jean-Yves Migeon a écrit :
>>> Okay, thanks for the report. So this rules out Virtual Box, it seems to
>>> happen on native amd64 too.
>>>
>>> I am taking a look right now.
>>
>> This seems to be a bug in the trap handling code. The si
Le 21/04/12 16:31, Jean-Yves Migeon a écrit :
Okay, thanks for the report. So this rules out Virtual Box, it seems to
happen on native amd64 too.
I am taking a look right now.
This seems to be a bug in the trap handling code. The signal is caught
correctly (it reaches T_ALIGNFLT|T_USER in trap
Le 21/04/12 14:50, Jean-Yves Migeon a écrit :
The machine did not drop into ddb, it simply rebooted. Unfortunately
it did not leave a core dump behind, so I don't have much to look at
just yet. When I get home later today, I will try to get more info.
BTW, this occurred while running the ATF tes
On Fri, 20 Apr 2012 15:33:05 -0700 (PDT), Paul Goyette wrote:
On Fri, 20 Apr 2012, Paul Goyette wrote:
XXX I would appreciate if someone could test it under a real amd64
host with an up-to-date kernel, so I can reasonably assume that the
culprit is Virtual Box and not our amd64 port (my test m
On Fri, 20 Apr 2012, Paul Goyette wrote:
The machine did not drop into ddb, it simply rebooted. Unfortunately it did
not leave a core dump behind, so I don't have much to look at just yet. When
I get home later today, I will try to get more info.
BTW, this occurred while running the ATF tes
On Fri, 20 Apr 2012, Paul Goyette wrote:
XXX I would appreciate if someone could test it under a real amd64 host
with an up-to-date kernel, so I can reasonably assume that the culprit is
Virtual Box and not our amd64 port (my test machine being off line I cannot
do it myself). Results from oth
XXX I would appreciate if someone could test it under a real amd64
host with an up-to-date kernel, so I can reasonably assume that the
culprit is Virtual Box and not our amd64 port (my test machine being
off line I cannot do it myself). Results from other arches would be a
plus too.
I just up
On Thu, Dec 30, 2010 at 10:21:53PM +, Antti Kantee wrote:
> Log Message:
> Test is no longer expected to hang.
>
> PR lib/44248 closed when test associate with PR fails ==> brick dholland
The bug was fixed, so I closed the PR. I don't have time to spend an
hour or two running tests every
33 matches
Mail list logo
