Hi Ivan,
Thank you for sharing your insights!
> > It would mean that Linux/e2k can hardly conform to
> > POSIX well, as Bruno said, because POSIX requires different signals for
> > different cases and incompatibilities can't be forgiven on the reason of
> > speculative computations in the CPU.
Here is a follow-up to the story, for those curious what happens in a
similar IA64 architecture. And this should be it.
As for the problem on E2K itself, we should discuss it with MCST and/or
investigate whether the missing information about the faults can be
recovered to better satisfy POSIX.
On Sat, Dec 29, 2018 at 06:03:42PM +0300, Ivan Zakharyaschev wrote:
[...]
> BTW, saving and forgetting the type of the original fault doesn't seem
> to be something expensive to implement (after some thought): when a
> register is marked as invalid, it shouldn't matter anymore what value
> it
Hi,
On Sat, 29 Dec 2018, Dmitry V. Levin wrote:
> On Fri, Dec 28, 2018 at 05:23:09PM +0300, Ivan Zakharyaschev wrote:
> > As for the SIGILL peculiarity, it has a reason in the Elbrus architecture.
> No, this particular case (++*argv[argc]) has nothing to do with tagged memory,
> I hope Ivan
Hi Bruno,
On Sat, 29 Dec 2018, Bruno Haible wrote:
> > "system in development" is the one which suits
> > Linux/E2k better. The port to E2K (MCST Elbrus general purpose hardware
> > architecture) is quite mature, but not yet released publicly.
>
> Thanks for the info. Based on it, I found a
Andrey Savchenko wrote:
> This is not possible. Four generations of hardware are already
> manufactured and they use SIGILL for such cases. It may be fixed in
> future generations if CPU designers will agree to do so
The mapping from hardware exception code to Unix signal number is done in
On Sat, Dec 29, 2018 at 02:31:11PM +0300, Andrey Savchenko wrote:
> On Sat, 29 Dec 2018 12:17:32 +0100 Bruno Haible wrote:
> > > As for the SIGILL peculiarity, it has a reason in the Elbrus
> > > architecture.
> > > ...
> > > And it's not a segmentation fault.
> >
> > I believe you should make
On Fri, Dec 28, 2018 at 05:23:09PM +0300, Ivan Zakharyaschev wrote:
> Hi Bruno,
>
> On Thu, 20 Dec 2018, Bruno Haible wrote:
>
> > > +# E2K (elbrus) systems send SIGILL on an access to an invalid
> > > address.
> >
> > This is a bug in the system. Access of an invalid address ought to
Hi all!
On Sat, 29 Dec 2018 12:17:32 +0100 Bruno Haible wrote:
> > As for the SIGILL peculiarity, it has a reason in the Elbrus architecture.
> > ...
> > And it's not a segmentation fault.
>
> I believe you should make it signal a SIGSEGV or SIGBUS, not SIGILL, for
> the following reasons:
>
>
Hi Ivan,
> "system in development" is the one which suits
> Linux/E2k better. The port to E2K (MCST Elbrus general purpose hardware
> architecture) is quite mature, but not yet released publicly.
Thanks for the info. Based on it, I found a couple of other pointers as well:
[1][2].
> As for
Hi Bruno,
On Thu, 20 Dec 2018, Bruno Haible wrote:
> > + # E2K (elbrus) systems send SIGILL on an access to an invalid
> > address.
>
> This is a bug in the system. Access of an invalid address ought to produce a
> SIGSEGV or SIGBUS.
>
> 'elbrus' is not an important OS so far, for which
Hi Ivan,
> +# E2K (elbrus) systems send SIGILL on an access to an invalid
> address.
This is a bug in the system. Access of an invalid address ought to produce a
SIGSEGV or SIGBUS.
'elbrus' is not an important OS so far, for which it would be worth adding
workarounds in the gnulib
I can think of two ways to think about the purpose of this test:
1. distinguish stack overflow from an access to an invalid address
("programm error")
2. distinguish stack overflow from other cases when SIGSEGV is sent
Under view 2, then the access to an invalid address is just an
13 matches
Mail list logo
