[RFC] Reliable compiler specification setting (at least include/lib dirs) through the process environment
Hello GCC and Clang devs!
Unlike the traditional approach of installing system libraries into one
central location like /usr/{lib,include}, the nix package manager [1]
installs each package into it's own prefix
(e.g. /nix/store/mn9kqag3d24v6q41x747zd7n5qnalch7-zlib-1.2.8-dev). Moreover,
each package is built in its own environment determined from its
explicitly listed dependencies, regardless of what else is installed on
the system. Because not all package build scripts properly respect
CFLAGS etc., we currently wrap the compiler [2] to respect custom
environment variables like NIX_CFLAGS_COMPILE, so during the build of a
package that depends on zlib and Xlib might have NIX_CFLAGS_COMPILE set
to "-isystem
/nix/store/bl0rz2xinsm9yslghd7n5vaba86zxknh-libX11-1.6.3-dev/include -isystem
/nix/store/mn9kqag3d24v6q41x747zd7n5qnalch7-zlib-1.2.8-dev/include".
Unfortunately, as you can see if you click through the link or look
through the git history, the wrapper is quite complex (frankly, hacky)
and has evolved mostly through trial and error. Moreover, it's known to
break things like response files [3] and is generally speaking a source
of frustration. I believe the situation would be much improved if gcc
and clang supported some form of "environment-specific" configuration,
either through environment variables or, if absolutely necessary,
command line flags that can be passed unconditionally (note, for
example, that we currently parse the cc command line to see if we're
going to do any linking before deciding to pass in linking-specific
options) and clearly have the semantics we want. Ideally we would be
able to specify something on the level of abstraction of "this directory
should be treated like you would normally treat /usr" and get
e.g. /include, /lib, frameworks on OS X, etc. handled properly.
Would patches aimed at achieving this be considered for inclusion
upstream? My current thought for a first step would be an environment
variable specifying a file with command line flags that are ignored by
the compiler driver in contexts where they are inapplicable or
overridden by other command line flags, but I'm definitely open to
guidance on how this should best be achieved from your perspective. I'm
happy to do the work needed to get this in place if there is interest,
please let me know!
Thanks,
Shea Levy
[1]: https://nixos.org/nix
[2]:
https://github.com/NixOS/nixpkgs/blob/8cbdd9d0c290e294a9d783c8868e738db05c9ce2/pkgs/build-support/cc-wrapper/cc-wrapper.sh
[3]:
https://github.com/NixOS/nixpkgs/commit/a421e7bd4a28c69bded8b17888325e31554f61a1
signature.asc
Description: PGP signature
Re: Question about sibling call epilogues & registers
On 10/15/2016 08:41 PM, Segher Boessenkool wrote: Hi Daniel, On Sat, Oct 15, 2016 at 01:45:12AM -0500, Daniel Santos wrote: The insn that's getting deleted is 75, where RCX is set. I'm starting to think that maybe df_analyze() presumes that my call (to the stub) is invalidating RCX, although it does not. It looks like you don't use add_function_usage_to on the call insn? Segher Oddly enough, I had forgotten to call add_function_usage_to() on my save stub (which I didn't post), but not the restore stub. So thanks for that psychic intervention. :) But if you look carefully, it's there, although it's hard to read because of all the line wrapping: (expr_list (use (reg:DI 4 si)) (nil))) Right now I'm using gdb and gradually walking through df_analyze() and learning how the data flow and problems work. I presume that I can find my answer somewhere in the "live register" data flow problem code . This eventually runs "dead code elimination" on this insn (during the "finalize" phase), so I believe that I'm getting closer to discovering the root cause. So the bright side is that I'm learning a lot more about gcc internals! Which is probably my main goal of this exercise. Daniel
Re: Question about sibling call epilogues & registers
On Sun, Oct 16, 2016 at 05:05:17PM -0500, Daniel Santos wrote: > >>The insn that's getting deleted is 75, where RCX is set. I'm starting > >>to think that maybe df_analyze() presumes that my call (to the stub) is > >>invalidating RCX, although it does not. > >It looks like you don't use add_function_usage_to on the call insn? > Oddly enough, I had forgotten to call add_function_usage_to() on my save > stub (which I didn't post), but not the restore stub. So thanks for that > psychic intervention. :) But if you look carefully, it's there, although > it's hard to read because of all the line wrapping: > > (expr_list (use (reg:DI 4 si)) > (nil))) But shouldn't it be marked as using RCX as well? > So the bright side is that I'm learning a lot more about > gcc internals! Which is probably my main goal of this exercise. :-) Segher
gcc-7-20161016 is now available
Snapshot gcc-7-20161016 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20161016/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 241222 You'll find: gcc-7-20161016.tar.bz2 Complete GCC MD5=e733c4c84b82a852bc5529f45358179c SHA1=9c79193c8bffe7614cc8664c1685629e53ca9ce2 Diffs from 7-20161009 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Question about sibling call epilogues & registers
On 10/16/2016 05:27 PM, Segher Boessenkool wrote: Oddly enough, I had forgotten to call add_function_usage_to() on my save stub (which I didn't post), but not the restore stub. So thanks for that psychic intervention. :) But if you look carefully, it's there, although it's hard to read because of all the line wrapping: (expr_list (use (reg:DI 4 si)) (nil))) But shouldn't it be marked as using RCX as well? So the bright side is that I'm learning a lot more about gcc internals! Which is probably my main goal of this exercise. :-) Segher Hehe, well no, it's the sibcall to LeaveCriticalSection that needs RCX. My stub isn't reading or touching it. Daniel
Who played with the GCC Bugzilla git repo?
Hello, Someone played with the GCC Bugzilla git repo last week with no real reason: Author: root Date: Fri Oct 7 15:28:43 2016 + snap-data Looks like the goal was to drop all CSS and JS files in data/assets/. Why? There is no reason to play with the data/ directory. This directory contains data generated by Bugzilla and is automatically cleaned up (and regenerated) by checksetup.pl when needed and so doesn't need to be cleaned up manually, and definitely not via git. data/ is in .gitignore for a reason! Moreover, this means that the GCC Bugzilla git repo is no longer in sync with the upstream Bugzilla git repo, because the one who played with git also committed my local changes (I didn't do it for a reason). I can no longer view my local changes, nor can I easily sync both repos with a fast-forward merge (I think). Could these changes be reverted to the exact point I left Bugzilla in May, i.e. 5.0.3 + my patch only? Frédéric
Make GCC emit ASM instructions in 'gcc/except.c' for i686 MinGW targets ?
Hi there,
I come up with an idea about implementing stack unwinding for
the i686-w64-mingw32 target using native Windows Structured
Exception Handling (a.k.a SEH) for efficiency reasons.
Unlike DWARF and SEH for x64, SEH for x86 is stack-based
and works like the SJLJ exception model: The operating system
keeps a thread specific pointer to an SEH node on the stack
that must be installed/uninstalled during run time.
The SEH-head pointer is stored in `fs:[0]`.
Typecially, an SEH handler is installed like this, in Intel syntax:
# typedef EXCEPTION_DISPOSITION
# filter_function(
# EXCEPTION_RECORD *record, void *establisher_frame,
# CONTEXT *machine_context, void *dispatcher_context)
# __attribute__((__cdecl__));
# struct x86_seh_node_header {
# struct x86_seh_node_header *next;
# filter_function *filter;
# char extra_data[];
# };
sub esp, 8 # struct x86_seh_node_header this_node;
mov ecx, dword ptr fs:[0] #
mov dword ptr[esp], ecx # this_node.next = get_thread_seh_head();
mov dword ptr[esp + 4], offset my_seh_filter
# this_node.filter = &my_seh_filter
mov dword ptr fs:[0], esp # set_thread_seh_head(&this_node);
Before the function exits and its frame is destroyed, the node
must be uninstalled like this:
mov ecx, dword ptr fs:[0] #
mov dword ptr fs:[0], ecx # set_thread_seh_head(this_node.next);
Since I am looking at the SJLJ exception model and it seems using
a slim, inlined version of `setjmp()` with `__builtin_longjmp()`
that only stores 3 or 4 pointers, extending that structure should be
a simple matter. The problem is that, installation and uninstallation
of SEH nodes require target-specific ASM code generation.
Is it possible to do in 'gcc/except.c' ?
--
Best regards,
lh_mouse
2016-10-17
Re: Question about sibling call epilogues & registers
I think I've finally found the problem. It would appear that if you do not explicitly add a note of type REG_CALL_DECL that specifies the function declaration then it will ignore whatever you've supplied with add_function_usage_to(). Instead, it will replace it with the target's default register clobber value which is almost everything: regs_invalidated_by_call is a macro defined in hard-reg-set.h and expands to (this_target_hard_regs->x_regs_invalidated_by_call). So it would seem that I need some type of function declaration. Daniel
