History log of /src/lib/libc/arch/or1k/sys |
Revision | Date | Author | Comments |
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
|