after rev 1.6 of m68k.md (which itself reverted a local patch that hadn't
been necessary for over a decade... see gcc bugzilla 12792).
discussed with christos and confirmed no regressions with the atf tests.
libpthread_dbg(3) is a remnant library from the M:N thread model
(pre-NetBSD-5.0) API to introspect threads within a process and for use
of debuggers.
Currently in the 1:1 model it's not used in GDB neither in LLDB and it's
not either planned to be used. It's current function to read pthread_t
structures is realizable within a regular debugger capable to
instrospect objects within a tracee (GDB, LLDB...).
pthread_dbg(3) is going to be removed from the base distribution and moved
to pkgsrc.
Patch reviewed by <christos>
Sponsored by <The NetBSD Foundation>
libpthread_dbg(3) is a remnant library from the M:N thread model
(pre-NetBSD-5.0) API to introspect threads within a process and for use
of debuggers.
Currently in the 1:1 model it's not used in GDB neither in LLDB and it's
not either planned to be used. It's current function to read pthread_t
structures is realizable within a regular debugger capable to
instrospect objects within a tracee (GDB, LLDB...).
pthread_dbg(3) is going to be removed from the base distribution and moved
to pkgsrc.
Patch reviewed by <christos>
Sponsored by <The NetBSD Foundation>
introducing since release of software to be recognised. This should hopefully
allow the builds to progress a littles further on systems such as the POWER8
which features a little endian 64-bit PowerPC CPU identified as ppc64le.
This change introduced ABI incompatible change with older versions shipped
on NetBSD. This back out code that is currently not working correctly due
to TLS-based std::call_once implementation in GNU libstdc++.
Error when starting gnuchash:
/usr/pkg/lib/libwebkitgtk-1.0.so.0: Undefined symbol "_ZSt15__once_callable" (symnum = 1705)
PR 51139
Reported by <wiz>
Currently std::call_once with libstdc++ works only with static linking.
Disable code path using __thread types and introduce FIXME_PR_51139.
Problem discussed in PR 51139
Functional std::call_once is required in LLVM and LLDB codebase.
Example code to test std::call_once:
#include <iostream>
#include <thread>
#include <mutex>
#include <cstdlib>
std::once_flag flag;
int main(int argc, char **argv)
{
std::call_once(flag, [](){ std::cout << "Simple example: called once\n"; });
return EXIT_SUCCESS;
}
Sponsored by <The NetBSD Foundation>
backport fix from upstream:
URL: https://gcc.gnu.org/viewcvs?rev=238789&root=gcc&view=rev
Log:
rs6000: Fix logic for when to emit .machine (PR71216)
The current logic determining whether to use .machine in the generated
asm code puts it there if the compiler is not configured with a default
target cpu, _or_ no -mcpu= was given on the command line. It should
be "and" instead.
PR target/71216
* config/rs6000/rs6000.c (rs6000_file_start): Fix condition for
when to emit a ".machine" pseudo-op.
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/rs6000.c
GNU ld for alpha is so clever that the redundant GP load in function
entrypoint is skipped. we must therefore skip initial GP loads; otherwise
breakpoints in function entrypoints can also be skipped.
Reported to upstream (Bug 20969):
https://sourceware.org/bugzilla/show_bug.cgi?id=20969
ok martin
libraries do, since they destructors need to still call millicode.
The problem this time was with /usr/pkg/bin/gdk-pixbuf-query-loaders
calling glib2's g_log...
netbsd_cpp_spec
netbsd_link_spec
netbsd_entry_point
netbsd_endfile_spec
use this in all netbsd targets.
XXX: 3 ports set this to EXTRA_SPECS instead of SUBTARGET_EXTRA_SPECS.
in libutil where the opd() function conflicts with the .opd section.
remove a couple of tainted defines that are handled differently now.
this, with mknative-gcc as well, enables ppc64 world to build again.
Update tsan (not enable, not tested, not compiling)
Merge common infrastructure.
XXX: Perhaps the common code should be made into a separate library?
Or always require asan?
src/external/mit/xorg/lib/libxcb/xkb.
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=231599
PR debug/67355
* var-tracking.c (reverse_op): Don't add dummy zero to reverse
ops that simplify back to the original value.
* alias.c (refs_newer_value_p): Cut off recursion for
expressions containing the original value.
_GNU_SOURCE to be defined for systems that need it (like glibc ones.)
be sure to find the right config.h for host programs.
these fixes combined make builds on debian 7 complete for me.
- earmv4 works (atf has one new failure, that seems common)
- mipsel run
- sparc runs
- sparc64 mostly works in UP mode
- add list of actual machines tested on
For several years I've been eager to find the time to fix the bugs
in C++ exceptions on VAX to get them working on NetBSD, because
theyâve been broken for many years and it looked like only a few
changes were needed to get them working. Without C++ exceptions,
the NetBSD test suite canât be run. The good news is that I was
able to fix all the bugs in the VAX machine description to make
C++ exceptions work in GCC 4.8.5 (version unimportant). I wrote a
blog post explaining the bugs, with patches:
Here's a short summary, with the diffs in text form at the end of this email.
1) Replace #define FRAME_POINTER_CFA_OFFSET(FNDECL) 0 with #define
ARG_POINTER_CFA_OFFSET(FNDECL) 0 in gcc/config/vax/elf.h and
gcc/config/vax/vax.h. This changes the definition of __builtin_dwarf_cfa()
to return %ap instead of %fp, which correctly points to CFA.
Previously, the stack unwinder was crashing in _Unwind_RaiseException()
trying to follow bad pointers from the initial CFA.
2) Define EH_RETURN_DATA_REGNO(N) to include only R2 and R3 (instead
of R2-R5) and add code to vax_expand_prologue() in gcc/config/vax/vax.c
to add R2-R3 to the procedure entry mask but only if crtl->calls_eh_return
is set. This fixes a crash when the stack unwinder tried to write
values to R2 and R3 in the previous stack frame via
__builtin_eh_return_data_regno (0) and __builtin_eh_return_data_regno (1).
3) Removed definitions of EH_RETURN_STACKADJ_RTX and STARTING_FRAME_OFFSET
from gcc/config/vax/elf.h. It's not necessary to remember the stack
adjustment or to waste four bytes on every stack frame for a value
that's not needed. Also remove the suspicious changes in
gcc/config/vax/vax.md to the definitions of call_pop and call_value
regarding DW_CFA_GNU_args_size and EH unwinding. I reverted to the
previous versions from an older version of GCC, adding a few useful
comments that had been removed.
4) The last bug is the one I understand the least. I'm hoping
someone reading this can implement a correct fix. What I was seeing
after making all the previous changes to fix the other bugs is that
my test program failed to catch any exceptions, but instead returned
normally to the original return path.
Investigation revealed that GCC was correctly generating the
necessary move instruction to copy the second parameter passed to
__builtin_eh_return() into the return address, because
EH_RETURN_HANDLER_RTX had been defined correctly in config/vax/elf.h.
Hereâs what the call looks like in gcc/except.c:
#ifdef EH_RETURN_HANDLER_RTX
rtx insn = emit_move_insn (EH_RETURN_HANDLER_RTX, crtl->eh.ehr_handler);
#else
error ("__builtin_eh_return not supported on this target");
#endif
The problem was that the optimizer is deleting the final move
instruction when I compile with -O or higher. The assembly code at
-O0 (no optimization) generated for the __builtin_eh_return() call
at the end of _Unwind_RaiseException() looked like:
calls $2,_Unwind_DebugHook
movl -12(%fp),%r1
movl %r1,16(%fp)
ret
.cfi_endproc
But then when I compiled with -O1 or -O2, all I saw was:
calls $2,_Unwind_DebugHook
ret
.cfi_endproc
This was a mystery for me and I donât know enough about how the
final peephole optimizer works to really track down why it thinks
it can remove the move call to store the previous return address.
My workaround was to add a call to RTX_FRAME_RELATED_P (insn) = 1;
after the emit_move_insn() in gcc/except.c, which was used in
vax_expand_prologue() to mark the procedure entry mask.
By making this change, the optimizer no longer removes the call to
write the value to the previous stack pointer, but it adds an extra
line of .cfi exception info, which seems unnecessary since the code
is immediately going to return from the call and any adjustment
made by the DWARF stack unwinder will already have been done. Hereâs
what the optimized code looks like with the patch (%r6 had been
loaded earlier):
calls $2,_Unwind_DebugHook
movl %r6,16(%fp)
.cfi_offset 6, -36
ret
.cfi_endproc
With that final change, C++ exception handling now finally works
on NetBSD/vax, and I was able to successfully run the vast majority
of the tests in the ATF testsuite, which had been completely
inaccessible when I started due to both atf-run and atf-report
immediately dumping core due to the bad pointers that I fixed. Now
I have a bunch of new bugs to track down fixes for, but I think
this was the hardest set of problems that needed to be solved to
bring NetBSD on VAX up to the level of the other NetBSD ports.
Here are the diffs I have so far. They should apply to any recent
version of GCC (tested on GCC 4.8.5). With the exception of the
hack to gcc/except.c, the other diffs are ready to submit to NetBSD
as well as to upstream GCC. The fix Iâd like to see for the final
problem I discovered of the emit_move_insn() being deleted by the
optimizer would be another patch to one of the files in the
gcc/config/vax directory to explain to the optimizer that writing
to 16(%fp) is important and not something to be deleted from the
epilogue (perhaps it thinks itâs writing to a local variable in
the frame that's about to be destroyed?).
I didn't see any indication that any other GCC ports required
anything special to tell the optimizer not to delete the move
instruction to EH_RETURN_HANDLER_RTX, so the other suspicion I have
is that there may be a bug specific to VAX's peephole optimizer or
related functions. Any ideas?
/usr/src/lib/csu/common/crt0-common.c: In function '___start':
/usr/src/lib/csu/common/crt0-common.c:184:1: internal compiler error: in dwf_regno, at dwarf2cfi.c:988
}
^
- explain the columns
- update arm status:
- MKCOMPAT problems with oabi
- coldfire builds as much as GCC 4.8
- sun2, m68k builds
- most mips builds now (mips64 has generic build issues)
- update sparc64 and ppc problems (sshd)
- there is something very very odd in linking libldap.so.4.3 where
using the GCC 4.8 compiler to link the GCC 5.3 compiled objects
works, or using GCC 5.3 compiler to link the 4.8 compiled objects
fails -- ie, the compiler output seems fine, but the interactions
between GCC and ld(1) are broken.
- add or1k, riscv*, ia64 and ppc64 columns:
- or1k and riscv* both fail, they need to have their support
ported to GCC 5.x (i understand that at least one of them
has a GCC 5.x tree.)
- expand the list of actually tested to complete "build.sh release"
to include machines, not just cpus.
- sshd problem is libldap.so.4.3, at least on sparc64. placing with 4.8 one works
- alpha mostly works fine, 7 new failures in atf, plus sshd problem
- update release build info for many *earm*, hppa, i386, amd64, mipsel, sh3*
- *mips* now at least completes mknative-gcc
- sh3eb has a mknative-gcc problem
