anymore. Look in the ucontext_t for the next frame
instead. Backtrace through a signal handler invocation
works now.
(Since this change is NetBSD specific, this code shouldn't
be in a file which is shared among BSDs.)
* elf64-sparc.c (sparc64_elf_adjust_dynamic_symbol): When linking a
non-shared object, do not reserve space in .plt and .rela.plt for
regular symbols neither defined nor referenced in shared objects.
This fixes firefox for Havard
"tradlittlemips" and "tradbigmips" vectors.
The old vectors are meant for IRIX with it prelink shared library
support, and changes to better support this in binutils 2.15 broke
shared library support under NetBSD. The "trad" vectors are what 32bit
Linux and OpenBSD also use.
These vectors are also compatible with older NetBSD-built shared
libraries and programs so no flag day is necessary (Yay!).
These changes from Nick Hudson. Help also from Charles Hannum.
not if the 64 bit type is defined (BFD_HOST_64_BIT) because the second
is always defined, even if it falls back to a 32 bit type. In our case,
this was not the problem; the problem was that we bfd_vma is a 32 bit
type when BFD64 is not defined, so the shift was out of range.
parse a #include'd file which does not pass S_ISREG() if the environment variable
CPP_RESTRICTED is set.
This is primarily intended for use by programs such as calendar(1) which
use cpp to parse untrusted user files -- without this change (and the corresponding
change to calendar(1)), any user can cause a denial-of-service for the daily
calendar -a run by #include'ing a named pipe.
Many thanks to christos@netbsd for his help in polishing this.
1) When looking up the active thread, do not convert it to a thread ID; use the
LWP ID instead. This causes us to go through the ptrace(2) interface to
modify registers -- using the kernel state -- rather than through the
thread library.
2) Do not add blocked threads to the thread list. These are represented by
LWPs and will be seen that way instead.
WARNING: i can't be 100% sure that this patch will work due to the x86-64
code being different from all other archs... maybe it ought to be
streamlined to the other archs?
Do not evaluate this->next after calling the handler; the handler may
have clobbered it. Resolves core dumps of cvs server on user ^C.
Ok'd by christos.
wiz