Home | History | Annotate | only in /src/lib/libc/arch/or1k/sys
History log of /src/lib/libc/arch/or1k/sys
RevisionDateAuthorComments
 1.1 03-Sep-2014  matt New files for OR1K support
 1.2 26-Oct-2021  christos Merge all MD __sigaction14_sigtramp.c copies into one:
- sparc and sparc64 were not using version 0 sigcontext when there were
no arguments in the signal version. This was probably a bug.
- vax is using +1 the version numbers of the other archs.
- Only hppa was defining __LIBC12_SOURCE__ so it was getting a working
sigcontext before. all the other ports that supported sigcontext had
the compat code disabled.
[pointed out by thorpej, thanks!]
If we want to remove sigcontext support from userland at least now there
is less work to do so.
 1.1 03-Sep-2014  matt New files for OR1K support
 1.1 03-Sep-2014  matt New files for OR1K support
 1.2 18-Apr-2020  thorpej Rename "syscall" to "_syscall" and provide "syscall" as a weak alias.
 1.1 03-Sep-2014  matt branches: 1.1.16;
New files for OR1K support
 1.1.16.1 21-Apr-2020  martin Sync with HEAD
 1.1 03-Sep-2014  matt New files for OR1K support
 1.1 03-Sep-2014  matt New files for OR1K support
 1.1 03-Sep-2014  matt New files for OR1K support
 1.2 07-Feb-2017  kamil Mark exect(3) obsolete and bind it to plain execve(2) on all platforms

The original exect(2) from BSD4.2 was enabling bit for tracing
(single-step mode) and calling execve(2). The purpose of it was to generate
a signal for a tracer once the application will change its image to a new
program.

This approach no longer works as:
- exect(2) traces (single-steps) libc and it requires hundreds or
thousands steps before entering a new image
- it's vax and x86 specific code
- this functionality has been moved to the kernel - once a process is
traced it will generate SIGTRAP with si_code TRAP_EXEC and route it to
its debugger
- the side effects and unportability make this interface unusable
- there are no known users of this interface
- it apparently never worked better since day0 of NetBSD ("day0 bug")

Users are requested to move to other execve(2) variants. Calling current
execve(2) as it is the most similar behavior to this one from BSD4.2.

Discussed several times on mailing lists and in PR/51700.

Add warning to exect(3) telling about marking this function obsolete.

This function is prepared to be removed in next libc major bump.

Sponsored by <The NetBSD Foundation>
 1.1 03-Sep-2014  matt branches: 1.1.2; 1.1.4;
New files for OR1K support
 1.1.4.1 21-Apr-2017  bouyer Sync with HEAD
 1.1.2.1 20-Mar-2017  pgoyette Sync with HEAD
 1.1 03-Sep-2014  matt New files for OR1K support
 1.1 03-Sep-2014  matt New files for OR1K support
 1.1 03-Sep-2014  matt New files for OR1K support
 1.1 03-Sep-2014  matt New files for OR1K support
 1.1 03-Sep-2014  matt New files for OR1K support
 1.1 03-Sep-2014  matt New files for OR1K support
 1.1 03-Sep-2014  matt New files for OR1K support

RSS XML Feed