illumos gcc 15.2.0 bringup#58
Conversation
This partially reverts commit f68e90a.
Stock GCC is overly willing to violate the ABI when calling local functions, such that it passes arguments in registers on i386. This hampers debugging with anything other than a fully-aware DWARF debugger, and is generally not something we desire. Implement a flag which disables this behaviour, enabled by default. The flag is global, though only effective on i386, to more easily allow its globalization later which, given the odds, is likely to be necessary.
Optimizations which clone functions to create call-specific implementations which may be better optimized also dissociate these functions from their symbol names in ways harmful to tracing and debugging (since there are now several implementations of a single source symbol, quite possibly none of them having the actual source symbol name). This allows any function cloning to be disabled, and makes any such optimization ineffective, and our source safe for debuggers everywhere.
…ropagation eliding or changing arguments
Originally implemented in:
commit 023cc9a
Author: jsm28 <jsm28@138bc75d-0d04-0410-961f-82ee72b054a4>
Date: Wed Jun 29 23:51:34 2005 +0000
* gcc/dwarf2.h (DW_AT_SUN_amd64_parmdump): New.
* gcc/dwarf2out.c (gen_subprogram_die): Add this attribute.
* gcc/doc/invoke.texi (-msave-args): New x86-64 option.
* gcc/config/i386/i386.h (MASK_SAVE_ARGS, TARGET_SAVE_ARGS): New.
(TARGET_SWITCHES): Add -msave-args.
* gcc/config/i386/i386.c (struct ix86_frame): Add nmsave_args and
padding0.
(pro_epilogue_adjust_stack): Declare.
(ix86_nsaved_args): New.
(override_options, ix86_can_use_return_insn_p,
ix86_frame_pointer_required, ix86_compute_frame_layout,
ix86_emit_save_regs, ix86_emit_save_regs_using_mov,
ix86_expand_prologue, ix86_expand_epilogue): Handle -msave-args.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/csl-sol210-3_4-branch@101443 138bc75d-0d04-0410-961f-82ee72b054a4
Reviewed by: Richard Lowe <richlowe@richlowe.net> Reviewed by: Robert Mustacchi <rm@joyent.com>
Reviewed by: Robert Mustacchi <rm@joyent.com> Reviewed by: Richard Lowe <richlowe@richlowe.net>
level or options to gcc - we like stack traces too much and it is of questionable benefit anyway, even on i386.
Originally from pkgsrc
The RTL is included directly in the test, and was generated without saved parameters. Attempting the test with -msave-args means the prologue and epilogue adjustments think there are saved parameters where there are not.
I did this, I think, to double check some assumptions. Unfortunately, there is a case where the fp won't be valid here, despite us having saved arguments. That where we're returning through an error handler via __builtin_eh_return(). While here, make the code more readable and conventional.
This will always fail if saving arguments, because we're testing argument registers are untouched, so saving them will ruin that.
We used to say it made no sense in 32bit mode, but it doesn't make sense in 16bit mode either
…-*.o contain debug info that should be stripped
Fix following error message:
$ /usr/gcc/9/bin/go build main.go
ar: bad option: -D
usage:
ar -d [-SvV] archive [file...]
ar -m [-SvV] [-{a|b|i} posname] archive [file...]
ar -p [-sSvV] archive [file ...]
ar -q [-cSvV] archive [file...]
ar -r [-cSuvV] [-{a|b|i} posname] archive [file...]
ar -t [-sSvV] archive [file...]
ar -x [-CsSTvV] archive [file...]
ar [-sSvV] archive
The error is harmless, no functionality issue, GCCGO runs Solaris "ar" which
doesn't know -D option, after failure, GCCGO runs it again without -D.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720 libobjc install-strip target not populated
…cause nothing else will work
Not all illumos distributions have elfdump available as /usr/ccs/bin/elfdump
From Jonathan Perkin's patch in pkgsrc-extra
…e encoded characters. C++'s locale interface can only cope with a single char or a single wchar_t.
|
@citrus-it do you have any notes on what's new or different in terms of the patches that we have here? |
Notes and test results added to PR description. |
rmustacc
left a comment
There was a problem hiding this comment.
Upstream gcc integrated "Remove obsolete Solaris 11.3 support" which, among other things, removed the code to detect whether libsocket.so and libnsl.so need to be explicitly linked. This is due to those being folded into libc in Solaris 11.4. The first new patch here restores that support and is a partial reversion of the upstream commit.
We provide sufficient crt files in the base system so we're okay on that part of the 11.3 removal?
In general I would prefer to deal with the locale stuff separately and land that on these branches once we're happy with it elsewhere and not have that block the rest of this.
| *cp++ = '.'; | ||
| *cp = '\0'; | ||
|
|
||
| /* Exclude directories that the linker is known to search. */ |
There was a problem hiding this comment.
Is there some other flag that we should be passing or some other way that we should be working with upstream to get a context where /usr/lib and /lib aren't being sent? Presumably when we're logically cross-compiling in illumos, then we don't want them to be sent. Versus assuming it's a linker choice in the long term.
| if (!exe_name) | ||
| { | ||
| const char *real_exe_name = PERSONALITY; | ||
| const char *real_exe_name = "g" PERSONALITY; |
There was a problem hiding this comment.
I know you mentioned that this was a new thing, but what's the impact on folks that are trying to find programs? Was it just that we always would have found it in a non-cross case at +200 and so this is only impact cross-building? The structure doesn't make that clear to me.
There were a number of changes required when bringing this set of patches forward from 14.3.
libsocket.soandlibnsl.soneed to be explicitly linked. This is due to those being folded into libc in Solaris 11.4. The first new patch here restores that support and is a partial reversion of the upstream commit.Use-GNU-backends-for-gcc-ar-nm-ranlibpatch gained a change in theCROSS_DIRECTORY_STRUCTUREsection, upstreamed back from illumos aarch64.-zassert-deflibpatch needed to be expanded as upstream removed the code that enabled it to work ("nobody is using it"). We previously had to patch this to enable 64-bit object support and now we have to patch for both.Testsuite results are all in the right ballpark compared to prior releases - the majority pass. Failures that I have spot checked are due to our reluctance to ever omit the frame pointer.