From: Rich Felker
Historically SH-2 Linux (and originally uClinux) used a syscall
calling convention incompatible with the established SH-3/4 Linux ABI.
This choice was made because the trap range used by the existing ABI,
0x10-0x17, overlaps with the hardware exception/interrupt trap range
From: Rich Felker dal...@libc.org
Historically SH-2 Linux (and originally uClinux) used a syscall
calling convention incompatible with the established SH-3/4 Linux ABI.
This choice was made because the trap range used by the existing ABI,
0x10-0x17, overlaps with the hardware exception/interrupt
From: Rich Felker
On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to
overlap with all but the last PAGE_SIZE bytes of the stack. This leads
to catastrophic memory reuse/corruption if brk is used. Fix by setting
the brk area to zero size to disable its use.
Signed-off-by: Rich
From: Rich Felker dal...@libc.org
On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to
overlap with all but the last PAGE_SIZE bytes of the stack. This leads
to catastrophic memory reuse/corruption if brk is used. Fix by setting
the brk area to zero size to disable its use
On Fri, Jun 19, 2015 at 12:06:26PM +0200, Ralf Baechle wrote:
> On Thu, Jun 18, 2015 at 10:50:32PM -0400, Rich Felker wrote:
>
> > This is kernel ABI breakage that should be fixed -- people running old
> > kernel versions with old musl binaries might suffer a regression
On Fri, Jun 19, 2015 at 12:06:26PM +0200, Ralf Baechle wrote:
On Thu, Jun 18, 2015 at 10:50:32PM -0400, Rich Felker wrote:
This is kernel ABI breakage that should be fixed -- people running old
kernel versions with old musl binaries might suffer a regression when
upgrading, and perhaps
On Fri, Jun 19, 2015 at 04:07:52AM +0200, Matthias Schiffer wrote:
> Hi,
> I've come across the issue that applications with detached threads
> (using pthread_detach or a pthread_attr_t with
> pthread_attr_setdetachstate) will segfault using musl-libc on MIPS as
> soon as the detached thread
On Fri, Jun 19, 2015 at 04:07:52AM +0200, Matthias Schiffer wrote:
Hi,
I've come across the issue that applications with detached threads
(using pthread_detach or a pthread_attr_t with
pthread_attr_setdetachstate) will segfault using musl-libc on MIPS as
soon as the detached thread exits. As
On Mon, Feb 16, 2015 at 06:20:18PM +0100, Arnd Bergmann wrote:
> > Would it really be that hard to do:
> >
> > if (ILP32_on_64_process) tv_nsec = (int)tv_nsec;
> >
> > or similar? That's all that's needed.
> >
> > > In some cases, there may also be a measurable performance penalty
> > > in
On Mon, Feb 16, 2015 at 03:40:54PM +0100, Arnd Bergmann wrote:
> On Friday 13 February 2015 13:37:07 Rich Felker wrote:
> > On Fri, Feb 13, 2015 at 05:33:46PM +, Catalin Marinas wrote:
> > > > > > The data structure definition is a little bit fragile,
On Mon, Feb 16, 2015 at 06:20:18PM +0100, Arnd Bergmann wrote:
Would it really be that hard to do:
if (ILP32_on_64_process) tv_nsec = (int)tv_nsec;
or similar? That's all that's needed.
In some cases, there may also be a measurable performance penalty
in interpreting a
On Mon, Feb 16, 2015 at 03:40:54PM +0100, Arnd Bergmann wrote:
On Friday 13 February 2015 13:37:07 Rich Felker wrote:
On Fri, Feb 13, 2015 at 05:33:46PM +, Catalin Marinas wrote:
The data structure definition is a little bit fragile, as it
depends on
user space not using
On Fri, Feb 13, 2015 at 05:33:46PM +, Catalin Marinas wrote:
> > > > The data structure definition is a little bit fragile, as it depends on
> > > > user space not using the __BIT_ENDIAN symbol in a conflicting way. So
> > > > far we have managed to keep that outside of general purpose
On Fri, Feb 13, 2015 at 01:33:56PM +, Catalin Marinas wrote:
> On Thu, Feb 12, 2015 at 07:59:24PM +0100, Arnd Bergmann wrote:
> > > Catalin Marinas hat am 12. Februar 2015 um 19:17
> > > geschrieben:
> > > On Wed, Feb 11, 2015 at 02:21:18PM -0500, Rich Felker
On Fri, Feb 13, 2015 at 01:33:56PM +, Catalin Marinas wrote:
On Thu, Feb 12, 2015 at 07:59:24PM +0100, Arnd Bergmann wrote:
Catalin Marinas catalin.mari...@arm.com hat am 12. Februar 2015 um 19:17
geschrieben:
On Wed, Feb 11, 2015 at 02:21:18PM -0500, Rich Felker wrote:
On Wed
On Fri, Feb 13, 2015 at 05:33:46PM +, Catalin Marinas wrote:
The data structure definition is a little bit fragile, as it depends on
user space not using the __BIT_ENDIAN symbol in a conflicting way. So
far we have managed to keep that outside of general purpose headers, but
it
On Thu, Feb 12, 2015 at 08:30:10AM -0800, H.J. Lu wrote:
> On Thu, Feb 12, 2015 at 7:50 AM, Catalin Marinas
> wrote:
> > On Wed, Feb 11, 2015 at 12:15:56PM -0800, Andy Lutomirski wrote:
> >> On 02/11/2015 11:57 AM, H.J. Lu wrote:
> >> trivially satisfied if you consider x32 and x86_64
On Thu, Feb 12, 2015 at 03:50:24PM +, Catalin Marinas wrote:
> On Wed, Feb 11, 2015 at 12:15:56PM -0800, Andy Lutomirski wrote:
> > On 02/11/2015 11:57 AM, H.J. Lu wrote:
> > trivially satisfied if you consider x32 and x86_64 separate
> > compilation environments, but it's not related
On Thu, Feb 12, 2015 at 03:50:24PM +, Catalin Marinas wrote:
On Wed, Feb 11, 2015 at 12:15:56PM -0800, Andy Lutomirski wrote:
On 02/11/2015 11:57 AM, H.J. Lu wrote:
trivially satisfied if you consider x32 and x86_64 separate
compilation environments, but it's not related to the core
On Thu, Feb 12, 2015 at 08:30:10AM -0800, H.J. Lu wrote:
On Thu, Feb 12, 2015 at 7:50 AM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Wed, Feb 11, 2015 at 12:15:56PM -0800, Andy Lutomirski wrote:
On 02/11/2015 11:57 AM, H.J. Lu wrote:
trivially satisfied if you consider x32 and
On Wed, Feb 11, 2015 at 10:02:55PM +0100, a...@arndb.de wrote:
> Rich Felker hat am 11. Februar 2015 um 21:12 geschrieben:
> > On Wed, Feb 11, 2015 at 08:50:06PM +0100, a...@arndb.de wrote:
> > > > > At least for AArch64 ILP32 we are still free to change the user/kernel
&g
On Wed, Feb 11, 2015 at 08:50:06PM +0100, a...@arndb.de wrote:
> > > At least for AArch64 ILP32 we are still free to change the user/kernel
> > > ABI, so we could add wrappers for the affected syscalls to fix this up.
> > >
> >
> > yes, afaik on x32 the 64bit kernel expects 64bit layout,
> > arm64
On Wed, Feb 11, 2015 at 11:34:23AM -0800, H.J. Lu wrote:
> On Wed, Feb 11, 2015 at 11:25 AM, Rich Felker wrote:
> > On Wed, Feb 11, 2015 at 11:16:58AM -0800, H.J. Lu wrote:
> >> >> > I don't know if this has been discussed on libc-alpha yet or not, but
> &
On Wed, Feb 11, 2015 at 11:16:58AM -0800, H.J. Lu wrote:
> >> > I don't know if this has been discussed on libc-alpha yet or not, but
> >> > I think we need to open a discussion of how it relates to open glibc
> >> > bug #16437, which presently applies only to x32 (ILP32 ABI on x86_64):
> >> >
>
On Wed, Feb 11, 2015 at 05:39:19PM +, Catalin Marinas wrote:
> (adding Marcus)
>
> On Tue, Feb 10, 2015 at 06:13:02PM +0000, Rich Felker wrote:
> > On Thu, 2 Oct 2014 at 16:52:18 +0100, Catalin Marinas wrote:
> > > On Wed, Sep 03, 2014 at 10:18:54PM +0100, Andrew P
On Wed, Feb 11, 2015 at 10:33:32AM -0800, H.J. Lu wrote:
> On Tue, Feb 10, 2015 at 10:13 AM, Rich Felker wrote:
> > On Thu, 2 Oct 2014 at 16:52:18 +0100, Catalin Marinas wrote:
> >> On Wed, Sep 03, 2014 at 10:18:54PM +0100, Andrew Pinski wrote:
> >> > New version wit
On Wed, Feb 11, 2015 at 11:16:58AM -0800, H.J. Lu wrote:
I don't know if this has been discussed on libc-alpha yet or not, but
I think we need to open a discussion of how it relates to open glibc
bug #16437, which presently applies only to x32 (ILP32 ABI on x86_64):
On Wed, Feb 11, 2015 at 10:33:32AM -0800, H.J. Lu wrote:
On Tue, Feb 10, 2015 at 10:13 AM, Rich Felker dal...@libc.org wrote:
On Thu, 2 Oct 2014 at 16:52:18 +0100, Catalin Marinas wrote:
On Wed, Sep 03, 2014 at 10:18:54PM +0100, Andrew Pinski wrote:
New version with all of the requested
On Wed, Feb 11, 2015 at 05:39:19PM +, Catalin Marinas wrote:
(adding Marcus)
On Tue, Feb 10, 2015 at 06:13:02PM +, Rich Felker wrote:
On Thu, 2 Oct 2014 at 16:52:18 +0100, Catalin Marinas wrote:
On Wed, Sep 03, 2014 at 10:18:54PM +0100, Andrew Pinski wrote:
New version
On Wed, Feb 11, 2015 at 11:34:23AM -0800, H.J. Lu wrote:
On Wed, Feb 11, 2015 at 11:25 AM, Rich Felker dal...@libc.org wrote:
On Wed, Feb 11, 2015 at 11:16:58AM -0800, H.J. Lu wrote:
I don't know if this has been discussed on libc-alpha yet or not, but
I think we need to open
On Wed, Feb 11, 2015 at 08:50:06PM +0100, a...@arndb.de wrote:
At least for AArch64 ILP32 we are still free to change the user/kernel
ABI, so we could add wrappers for the affected syscalls to fix this up.
yes, afaik on x32 the 64bit kernel expects 64bit layout,
arm64 can fix this
On Wed, Feb 11, 2015 at 10:02:55PM +0100, a...@arndb.de wrote:
Rich Felker dal...@libc.org hat am 11. Februar 2015 um 21:12 geschrieben:
On Wed, Feb 11, 2015 at 08:50:06PM +0100, a...@arndb.de wrote:
At least for AArch64 ILP32 we are still free to change the user/kernel
ABI, so we
On Thu, 2 Oct 2014 at 16:52:18 +0100, Catalin Marinas wrote:
> On Wed, Sep 03, 2014 at 10:18:54PM +0100, Andrew Pinski wrote:
> > New version with all of the requested changes. Updated to the
> > latest sources.
> >
> > Notable changes from the previous versions:
> > VDSO code has been factored
On Thu, 2 Oct 2014 at 16:52:18 +0100, Catalin Marinas wrote:
On Wed, Sep 03, 2014 at 10:18:54PM +0100, Andrew Pinski wrote:
New version with all of the requested changes. Updated to the
latest sources.
Notable changes from the previous versions:
VDSO code has been factored out to be
On Mon, Jan 12, 2015 at 11:33:49AM +, David Drysdale wrote:
> On Sat, Jan 10, 2015 at 1:33 AM, Rich Felker wrote:
> > On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote:
> >> Rich Felker writes:
> >>
> >> > I'm not proposing code be
On Mon, Jan 12, 2015 at 11:33:49AM +, David Drysdale wrote:
On Sat, Jan 10, 2015 at 1:33 AM, Rich Felker dal...@aerifal.cx wrote:
On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote:
Rich Felker dal...@aerifal.cx writes:
I'm not proposing code because I'm a libc
On Sat, Jan 10, 2015 at 04:27:23PM -0600, Eric W. Biederman wrote:
> Rich Felker writes:
>
> > On Sat, Jan 10, 2015 at 04:14:57AM +, Al Viro wrote:
>
> >> Except that if your interpreter does stat(2) (or access(2), or getxattr(2),
> >> etc.) before bothering
On Sat, Jan 10, 2015 at 09:27:46AM +0100, Michael Kerrisk (man-pages) wrote:
> On 01/09/2015 06:46 PM, David Drysdale wrote:
> > On Fri, Jan 9, 2015 at 4:13 PM, Rich Felker wrote:
> >> On Fri, Jan 09, 2015 at 04:47:31PM +0100, Michael Kerrisk (man-pages)
> >> wrote:
&
On Sat, Jan 10, 2015 at 09:27:46AM +0100, Michael Kerrisk (man-pages) wrote:
On 01/09/2015 06:46 PM, David Drysdale wrote:
On Fri, Jan 9, 2015 at 4:13 PM, Rich Felker dal...@aerifal.cx wrote:
On Fri, Jan 09, 2015 at 04:47:31PM +0100, Michael Kerrisk (man-pages)
wrote:
On 11/24/2014 12:53
On Sat, Jan 10, 2015 at 04:27:23PM -0600, Eric W. Biederman wrote:
Rich Felker dal...@aerifal.cx writes:
On Sat, Jan 10, 2015 at 04:14:57AM +, Al Viro wrote:
Except that if your interpreter does stat(2) (or access(2), or getxattr(2),
etc.) before bothering with open(2), you'll get
On Sat, Jan 10, 2015 at 04:14:57AM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 10:41:44PM -0500, Rich Felker wrote:
> > > _After_ the traversal it's too late to do this sort of thing - after all,
> > > how do you tell if your current position had been set by the traversal
On Sat, Jan 10, 2015 at 03:03:00AM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 11:36:44PM +, Al Viro wrote:
> > On Fri, Jan 09, 2015 at 06:12:48PM -0500, Rich Felker wrote:
> >
> > > I'm not sure where you're disagreeing with me. open of procfs symlinks
> >
On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote:
> Rich Felker writes:
>
> > I'm not proposing code because I'm a libc developer not a kernel
> > developer. I know what's needed for userspace to provide a conforming
> > fexecve to applicatio
On Fri, Jan 09, 2015 at 03:24:12PM -0800, Andy Lutomirski wrote:
> On Fri, Jan 9, 2015 at 3:12 PM, Rich Felker wrote:
> > On Fri, Jan 09, 2015 at 10:57:43PM +, Al Viro wrote:
> >> On Fri, Jan 09, 2015 at 05:42:52PM -0500, Rich Felker wrote:
> >>
> >> >
On Fri, Jan 09, 2015 at 10:57:43PM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 05:42:52PM -0500, Rich Felker wrote:
>
> > Here's a very simple way it could work -- it could put the O_PATH fd
> > on a previously-unused fd number, and put a special flag on the fd,
&
On Fri, Jan 09, 2015 at 10:33:00PM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 05:17:28PM -0500, Rich Felker wrote:
> > > Back then the procfs-free environments had been pushed as a serious
> > > argument
> > > in favour of merging the damn thing. No
On Fri, Jan 09, 2015 at 04:13:27PM -0600, Eric W. Biederman wrote:
> Rich Felker writes:
>
> > On Fri, Jan 09, 2015 at 09:09:41PM +, Al Viro wrote:
>
> > The "magic open-once magic symlink" approach is really the cleanest
> > solution I can find. I
On Fri, Jan 09, 2015 at 09:50:42PM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 04:28:52PM -0500, Rich Felker wrote:
>
> > The "magic open-once magic symlink" approach is really the cleanest
> > solution I can find. In the case where the interpreter does not
On Fri, Jan 09, 2015 at 03:20:04PM -0600, Eric W. Biederman wrote:
> Rich Felker writes:
>
> > On Fri, Jan 09, 2015 at 08:56:26PM +, Al Viro wrote:
> >> On Fri, Jan 09, 2015 at 03:48:15PM -0500, Rich Felker wrote:
> >> > I think this is a case that ne
On Fri, Jan 09, 2015 at 09:09:41PM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 03:59:26PM -0500, Rich Felker wrote:
>
> > > For fsck sake, folks, if you have bloody /proc, you don't need that shite
> > > at all! Just do execve on /proc/self/fd/n, and be done with tha
On Fri, Jan 09, 2015 at 08:56:26PM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 03:48:15PM -0500, Rich Felker wrote:
> > I think this is a case that needs to be fixed, though it's hard. The
> > normal correct usage for fexecve is to always pass an O_CLOEXEC file
> > descr
On Fri, Jan 09, 2015 at 05:46:28PM +, David Drysdale wrote:
> > It's AT_EXECFN,
> > /proc/self/exe, and filenames shown elsewhere in /proc that may be
> > derived in odd ways.
> >
> > I would also move the text about O_CLOEXEC to a BUGS or NOTES section
> > rather than the main description.
On Fri, Jan 09, 2015 at 04:47:31PM +0100, Michael Kerrisk (man-pages) wrote:
> On 11/24/2014 12:53 PM, David Drysdale wrote:
> > Signed-off-by: David Drysdale
> > ---
> > man2/execveat.2 | 153
> >
> > 1 file changed, 153 insertions(+)
>
On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote:
Rich Felker dal...@aerifal.cx writes:
I'm not proposing code because I'm a libc developer not a kernel
developer. I know what's needed for userspace to provide a conforming
fexecve to applications, not how to implement
On Sat, Jan 10, 2015 at 03:03:00AM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 11:36:44PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 06:12:48PM -0500, Rich Felker wrote:
I'm not sure where you're disagreeing with me. open of procfs symlinks
does not resolve the symlink and open
On Sat, Jan 10, 2015 at 04:14:57AM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 10:41:44PM -0500, Rich Felker wrote:
_After_ the traversal it's too late to do this sort of thing - after all,
how do you tell if your current position had been set by the traversal of
your symlink
On Fri, Jan 09, 2015 at 03:24:12PM -0800, Andy Lutomirski wrote:
On Fri, Jan 9, 2015 at 3:12 PM, Rich Felker dal...@aerifal.cx wrote:
On Fri, Jan 09, 2015 at 10:57:43PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 05:42:52PM -0500, Rich Felker wrote:
Here's a very simple way it could
On Fri, Jan 09, 2015 at 04:47:31PM +0100, Michael Kerrisk (man-pages) wrote:
On 11/24/2014 12:53 PM, David Drysdale wrote:
Signed-off-by: David Drysdale drysd...@google.com
---
man2/execveat.2 | 153
1 file changed, 153
On Fri, Jan 09, 2015 at 04:13:27PM -0600, Eric W. Biederman wrote:
Rich Felker dal...@aerifal.cx writes:
On Fri, Jan 09, 2015 at 09:09:41PM +, Al Viro wrote:
The magic open-once magic symlink approach is really the cleanest
solution I can find. In the case where the interpreter does
On Fri, Jan 09, 2015 at 10:33:00PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 05:17:28PM -0500, Rich Felker wrote:
Back then the procfs-free environments had been pushed as a serious
argument
in favour of merging the damn thing. Now you guys turn around and say
that
we
On Fri, Jan 09, 2015 at 09:50:42PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 04:28:52PM -0500, Rich Felker wrote:
The magic open-once magic symlink approach is really the cleanest
solution I can find. In the case where the interpreter does not open
the script, nothing terribly bad
On Fri, Jan 09, 2015 at 10:57:43PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 05:42:52PM -0500, Rich Felker wrote:
Here's a very simple way it could work -- it could put the O_PATH fd
on a previously-unused fd number, and put a special flag on the fd,
like FD_CLOEXEC, but that causes
On Fri, Jan 09, 2015 at 05:46:28PM +, David Drysdale wrote:
It's AT_EXECFN,
/proc/self/exe, and filenames shown elsewhere in /proc that may be
derived in odd ways.
I would also move the text about O_CLOEXEC to a BUGS or NOTES section
rather than the main description. The long-term
On Fri, Jan 09, 2015 at 08:56:26PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 03:48:15PM -0500, Rich Felker wrote:
I think this is a case that needs to be fixed, though it's hard. The
normal correct usage for fexecve is to always pass an O_CLOEXEC file
descriptor, and the caller can't
On Fri, Jan 09, 2015 at 03:20:04PM -0600, Eric W. Biederman wrote:
Rich Felker dal...@aerifal.cx writes:
On Fri, Jan 09, 2015 at 08:56:26PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 03:48:15PM -0500, Rich Felker wrote:
I think this is a case that needs to be fixed, though it's hard
On Fri, Jan 09, 2015 at 09:09:41PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 03:59:26PM -0500, Rich Felker wrote:
For fsck sake, folks, if you have bloody /proc, you don't need that shite
at all! Just do execve on /proc/self/fd/n, and be done with that.
The sole excuse
On Tue, Oct 07, 2014 at 07:18:33PM -0500, Chuck Ebbert wrote:
> On Tue, 7 Oct 2014 16:59:03 -0700
> David Daney wrote:
>
> > On 10/07/2014 04:20 PM, Ralf Baechle wrote:
> > > On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
> > >
> > >>> As an alternative, if the space of possible
On Tue, Oct 07, 2014 at 12:16:59PM -0700, Leonid Yegoshin wrote:
> On 10/07/2014 12:09 PM, Rich Felker wrote:
> >I agree completely here. We should not break things (or, as it
> >seems, leave them broken) for common usage cases that affect
> >everyone just to coddle propri
On Tue, Oct 07, 2014 at 11:44:35AM -0700, Andy Lutomirski wrote:
> > 4) The voice for doing any instruction emulation in kernel - it is not a
> > MIPS business model to force customer to put details of all Coprocessor 2
> > instructions public. We provide an interface and the rest is a customer
>
On Tue, Oct 07, 2014 at 09:13:22AM +, Matthew Fortune wrote:
> From what I can see the out-of-line execution of delay slot instructions
> will break micromips R3 addiupc, and all MIPS32r6 and MIPS64r6 PC-relative
> instructions (inc load/store) as they will have the wrong base. Is there
>
On Mon, Oct 06, 2014 at 09:50:47PM -0700, David Daney wrote:
> >>the out-of-line execution trick, but do it somewhere other than in
> >>stack memory.
> >How do you answer Andy Lutomirski's question about what happens when a
> >signal handler interrupts execution while the program counter is
>
On Mon, Oct 06, 2014 at 09:50:47PM -0700, David Daney wrote:
the out-of-line execution trick, but do it somewhere other than in
stack memory.
How do you answer Andy Lutomirski's question about what happens when a
signal handler interrupts execution while the program counter is
pointing at
On Tue, Oct 07, 2014 at 09:13:22AM +, Matthew Fortune wrote:
From what I can see the out-of-line execution of delay slot instructions
will break micromips R3 addiupc, and all MIPS32r6 and MIPS64r6 PC-relative
instructions (inc load/store) as they will have the wrong base. Is there
anything
On Tue, Oct 07, 2014 at 11:44:35AM -0700, Andy Lutomirski wrote:
4) The voice for doing any instruction emulation in kernel - it is not a
MIPS business model to force customer to put details of all Coprocessor 2
instructions public. We provide an interface and the rest is a customer
On Tue, Oct 07, 2014 at 12:16:59PM -0700, Leonid Yegoshin wrote:
On 10/07/2014 12:09 PM, Rich Felker wrote:
I agree completely here. We should not break things (or, as it
seems, leave them broken) for common usage cases that affect
everyone just to coddle proprietary vendor-specific
On Tue, Oct 07, 2014 at 07:18:33PM -0500, Chuck Ebbert wrote:
On Tue, 7 Oct 2014 16:59:03 -0700
David Daney dda...@caviumnetworks.com wrote:
On 10/07/2014 04:20 PM, Ralf Baechle wrote:
On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
As an alternative, if the space of
On Mon, Oct 06, 2014 at 06:02:20PM -0700, Kevin D. Kissell wrote:
> On 10/06/2014 01:23 PM, David Daney wrote:
> >From: David Daney
> >
> >In order for MIPS to be able to support a non-executable stack, we
> >need to supply a method to specify a userspace area that can be used
> >for executing
On Mon, Oct 06, 2014 at 05:33:18PM -0700, David Daney wrote:
> On 10/06/2014 05:05 PM, Rich Felker wrote:
> >On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
> >>On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
> >>>On 10/06/2014 02:58 PM, Rich Felker wro
On Mon, Oct 06, 2014 at 05:11:38PM -0700, Andrew Pinski wrote:
> On Mon, Oct 6, 2014 at 5:05 PM, Rich Felker wrote:
> > On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
> >> On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
> >> >On 10/06/2014 02:58 PM, Ri
On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
> On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
> >On 10/06/2014 02:58 PM, Rich Felker wrote:
> >>On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
> [...]
> >>This is a huge ill-designed
On Mon, Oct 06, 2014 at 03:17:03PM -0700, David Daney wrote:
> >>Furthermore the
> >>userspace code has to be very careful in its use of the $sp
> >>register, so that it doesn't store data in places that will be
> >>used/clobbered by the kernel.
> >
> >This is not "being careful". The stack
On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
> On 10/06/2014 02:31 PM, Rich Felker wrote:
> >On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
> >>>Userspace should play no part in this; requiring userspace to help
> >>>make specia
On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
> >Userspace should play no part in this; requiring userspace to help
> >make special accomodations for fpu emulation largely defeats the
> >purpose of fpu emulation.
>
> That is certainly one way of looking at it. Really it is
On Mon, Oct 06, 2014 at 01:23:30PM -0700, David Daney wrote:
> From: David Daney
>
> In order for MIPS to be able to support a non-executable stack, we
> need to supply a method to specify a userspace area that can be used
> for executing emulated branch delay slot instructions.
>
> We add a
On Mon, Oct 06, 2014 at 01:23:30PM -0700, David Daney wrote:
From: David Daney david.da...@cavium.com
In order for MIPS to be able to support a non-executable stack, we
need to supply a method to specify a userspace area that can be used
for executing emulated branch delay slot instructions.
On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
Userspace should play no part in this; requiring userspace to help
make special accomodations for fpu emulation largely defeats the
purpose of fpu emulation.
That is certainly one way of looking at it. Really it is opinion,
On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
On 10/06/2014 02:31 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
Userspace should play no part in this; requiring userspace to help
make special accomodations for fpu emulation largely defeats
On Mon, Oct 06, 2014 at 03:17:03PM -0700, David Daney wrote:
Furthermore the
userspace code has to be very careful in its use of the $sp
register, so that it doesn't store data in places that will be
used/clobbered by the kernel.
This is not being careful. The stack pointer can never become
On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
On 10/06/2014 02:58 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
[...]
This is a huge ill-designed mess.
Amen.
Can the kernel not just
On Mon, Oct 06, 2014 at 05:11:38PM -0700, Andrew Pinski wrote:
On Mon, Oct 6, 2014 at 5:05 PM, Rich Felker dal...@libc.org wrote:
On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
On 10/06/2014 02:58 PM, Rich Felker wrote:
On Mon
On Mon, Oct 06, 2014 at 05:33:18PM -0700, David Daney wrote:
On 10/06/2014 05:05 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
On 10/06/2014 02:58 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 02:45:29PM
On Mon, Oct 06, 2014 at 06:02:20PM -0700, Kevin D. Kissell wrote:
On 10/06/2014 01:23 PM, David Daney wrote:
From: David Daney david.da...@cavium.com
In order for MIPS to be able to support a non-executable stack, we
need to supply a method to specify a userspace area that can be used
for
On Fri, Jun 20, 2014 at 08:55:01AM -0700, Andy Lutomirski wrote:
> On Mon, Jun 16, 2014 at 8:42 AM, Rich Felker wrote:
> > On Mon, Jun 16, 2014 at 08:31:39AM -0700, Ian Lance Taylor wrote:
> >> On Mon, Jun 16, 2014 at 7:38 AM, Andi Kleen wrote:
> >> >> I t
On Fri, Jun 20, 2014 at 08:55:01AM -0700, Andy Lutomirski wrote:
On Mon, Jun 16, 2014 at 8:42 AM, Rich Felker dal...@libc.org wrote:
On Mon, Jun 16, 2014 at 08:31:39AM -0700, Ian Lance Taylor wrote:
On Mon, Jun 16, 2014 at 7:38 AM, Andi Kleen a...@firstfloor.org wrote:
I think this issue
On Mon, Jun 16, 2014 at 08:31:39AM -0700, Ian Lance Taylor wrote:
> On Mon, Jun 16, 2014 at 7:38 AM, Andi Kleen wrote:
> >> I think this issue started when some of the Go developers questioned
> >> why the kernel needed to provide a very complex interface--parsing an
> >> ELF shared shared
On Mon, Jun 16, 2014 at 04:38:01PM +0200, Andi Kleen wrote:
> > I think this issue started when some of the Go developers questioned
> > why the kernel needed to provide a very complex interface--parsing an
> > ELF shared shared library--for very simple functionality--looking up
> > the address of
On Mon, Jun 16, 2014 at 07:08:50AM -0700, Ian Lance Taylor wrote:
> On Sun, Jun 15, 2014 at 7:36 PM, Andi Kleen wrote:
> >
> > I haven't looked into this in detail, but my initial assumption would
> > be that it wouldn't be useful to add new vdso interfaces just for Go.
> > After all would you
On Sun, Jun 15, 2014 at 11:22:48AM -0700, Andy Lutomirski wrote:
> >>[1] The only comprehensible description of the GNU hash extension that
> >>I could find is on Oracle's blog (!)
> >>
> >
> > Curious about this blog. We do have a GNU hash implementation in Syslinux,
> > too, for another
On Sun, Jun 15, 2014 at 11:22:48AM -0700, Andy Lutomirski wrote:
[1] The only comprehensible description of the GNU hash extension that
I could find is on Oracle's blog (!)
Curious about this blog. We do have a GNU hash implementation in Syslinux,
too, for another reference.
On Mon, Jun 16, 2014 at 07:08:50AM -0700, Ian Lance Taylor wrote:
On Sun, Jun 15, 2014 at 7:36 PM, Andi Kleen a...@firstfloor.org wrote:
I haven't looked into this in detail, but my initial assumption would
be that it wouldn't be useful to add new vdso interfaces just for Go.
After all
801 - 900 of 950 matches
Mail list logo
