Coming back to the subject of signal preemptors...
Why do we need them at all? Why not just use the existing POSIX signal
facilities?
We install a signal handler, saving the old signal handler, check the
faulting memory address inside the new signal handler, and relay the signal
on to the saved
On Wed, Nov 23, 2016 at 10:03 PM, Brent W. Baccala
wrote:
>
> Any comments?
>
Well, yes, actually. :-)
gdb's hurd target has a poorly documented command "set noninvasive". I
don't completely understand it, but...
I'm starting to see the rational for an "invasive"
On Fri, Nov 25, 2016 at 1:46 AM, Thomas Schwinge
wrote:
> Hi!
>
> Motivation for bringing this up again: GDB has recently switched from
> using a C to a C++ compiler. GDB, for obvious reasons, needs to access
> low-level Hurd/Mach interfaces.
>
>
I've also had problems
установка и ремонт домофонов видеодомофонов и систем видеонаблюдения
http://pulsarvideo.ru/
* src_libgo_runtime_netpoll.goc.diff: Fix restricted word bug.
Rename variable errno to errno1.
* src_libgo_go_os_os_test.go.diff: Allow EFBIG return code to big
seeks.
* src_libgo_go_syscall_syscall_gnu_test.go: New file:
Define Type and Whence as 32bit in syscall.Flock_t
*
Hi,
Attached are patches to enable gccgo to build properly on Debian
GNU/Hurd on gcc-6 (6-6.2.1-5).
The first three patches are Debian-specific:
* debian_rules.defs.diff: Enables build of gccgo for GNU/Hurd
Define patches for the generated series file:
* debian_rules.patch.diff: Enables