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.
>
Necktwi Ozfguah wrote:
> Its coreutils-8.30
That's good; recent enough.
> I've untared coreutils-8.30.tar.xz
> cd coreutils-8.30
> ./bootstrap
> ./configure CFLAGS="-march=armv8-a+crc -mtune=cortex-a53 -mcpu=cortex-a53
> -ftree-vectorize -O2 -pipe -fomit-frame-pointer -Wno-error" CXXFLAGS=$CFLAG
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.
Hello,
On 2018-12-29 7:51 a.m., Necktwi Ozfguah wrote:
Its coreutils-8.30 with musl-1.1.20 Linux aarch64, Gentoo. I've untared
coreutils-8.30.tar.xz cd coreutils-8.30 ./bootstrap ./configure
CFLAGS="-march=armv8-a+crc -mtune=cortex-a53 -mcpu=cortex-a53
-ftree-vectorize -O2 -pipe -fomit-frame-
On Sat, Dec 29, 2018 at 09:22:17AM -0800, Paul Eggert wrote:
> (Using ptrdiff_t is part of my campaign to prefer ptrdiff_t to size_t. While
> we're at it, let's change the other size_t args to ptrdiff_t, but I
> digress)
Have you said anything about this campaign elsewhere? I'd like to hear
m
I suspect that changing this behavior would be a disruptive
backwards-incompatible change (but other opinions are welcomed).
I wouldn't mind a change as long as it changes the API enough so that compilers
complain if we don't also update the calling code. For example, nstrftime could
take an a
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 holds
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 wi
On 2018-12-28 11:08 p.m., Bruno Haible wrote:
[CCing Florian Weimer.
Florian, the thread started at
https://lists.gnu.org/archive/html/bug-gnulib/2018-12/msg00149.html ]
Assaf Gordon wrote:
The comment even says:
/* Unknown format; output the format, including the '%',
since
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 co
I wrote:
> I believe you should make it signal a SIGSEGV or SIGBUS, not SIGILL, for
> the following reasons:
A third reason is that the application will want to react depending on the
memory address which produced the fault. (I mean the memory address of the
data, not of the instruction.) This mem
Hello,
We'll need a bit more technical information to troubleshoot
the issue:
On 2018-12-29 1:22 a.m., Necktwi Ozfguah wrote:
While I am building coreutils with musl on aarch64 (RaspberryPi 3B),
Which operating system and which version are you using?
The output of "uname -a" would be helpf
Its coreutils-8.30 with musl-1.1.20 Linux aarch64, Gentoo.
I've untared coreutils-8.30.tar.xz
cd coreutils-8.30
./bootstrap
./configure CFLAGS="-march=armv8-a+crc -mtune=cortex-a53 -mcpu=cortex-a53
-ftree-vectorize -O2 -pipe -fomit-frame-pointer -Wno-error" CXXFLAGS=$CFLAGS
--prefix="/usr"
make -
Hi,
Necktwi Ozfguah wrote:
> While I am building coreutils with musl on aarch64 (RaspberryPi 3B), this
> error is thrown:
> lib/freadseek.c: In function 'freadptrinc':
> lib/freadseek.c:69:3: error: #error "Please port gnulib freadseek.c to your
> platform! Look at the definition of getc, getc_
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
softwar
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 i
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 produ
Hi,
While I am building coreutils with musl on aarch64 (RaspberryPi 3B), this
error is thrown:
lib/freadseek.c: In function 'freadptrinc':
lib/freadseek.c:69:3: error: #error "Please port gnulib freadseek.c to your
platform! Look at the definition of getc, getc_unlocked on your system, then
re
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 the
20 matches
Mail list logo
