Message ID | 1445352975-17844-22-git-send-email-gbenson@redhat.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 66848 invoked by alias); 20 Oct 2015 15:04:28 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 66789 invoked by uid 89); 20 Oct 2015 15:04:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com From: Gary Benson <gbenson@redhat.com> To: libc-alpha@sourceware.org Subject: [RFC][PATCH 21/22] Add Makerules to build %.o and %.os from %.i8 Date: Tue, 20 Oct 2015 15:56:14 +0100 Message-Id: <1445352975-17844-22-git-send-email-gbenson@redhat.com> In-Reply-To: <1445352975-17844-1-git-send-email-gbenson@redhat.com> References: <1445352975-17844-1-git-send-email-gbenson@redhat.com> |
Commit Message
Gary Benson
Oct. 20, 2015, 2:56 p.m. UTC
This commit adds make rules to build %.o and %.os files from %.i8 Infinity note source code. In order to ensure the correct preprocessor and assembler are used for cross-builds the compilation is done in three stages. The target preprocessor specified at ./configure time is used to preprocess the %.i8 source; I8C consumes this preprocessed source and emits assembly language; and finally the target assembler specified at ./configure time is used to assemble the generated assembly language into object code. I don't *think* the %.o and %.os files should differ (they don't contain "real" code, just PT_NOTE sections) but please tell me if I'm wrong and I will add a separate %.S -> %.os rule. --- Makerules | 16 ++++++++++++++++ 1 files changed, 16 insertions(+), 0 deletions(-)
Comments
On Tue, 20 Oct 2015, Gary Benson wrote: > This commit adds make rules to build %.o and %.os files from %.i8 > Infinity note source code. > > In order to ensure the correct preprocessor and assembler are used > for cross-builds the compilation is done in three stages. The target > preprocessor specified at ./configure time is used to preprocess the > %.i8 source; I8C consumes this preprocessed source and emits assembly > language; and finally the target assembler specified at ./configure > time is used to assemble the generated assembly language into object > code. > > I don't *think* the %.o and %.os files should differ (they don't > contain "real" code, just PT_NOTE sections) but please tell me if > I'm wrong and I will add a separate %.S -> %.os rule. On some platforms the options passed to GCC when compiling a .S file affect the options passed to the assembler, which in turn affects the ELF header (this applies e.g. to MIPS passing -KPIC). So I think you do need to compile the files separately. On some platforms, even assembler files with no actual code need to contain certain assembler directives to be ABI-compatible with those generated by the compiler. In particular, this applies to ARM; see the .eabi_attribute directives in sysdeps/arm/sysdep.h. If generating a .S file, you should make sure it includes <sysdep.h> so that such directives are present.
Joseph Myers wrote: > On Tue, 20 Oct 2015, Gary Benson wrote: > > This commit adds make rules to build %.o and %.os files from %.i8 > > Infinity note source code. > > > > In order to ensure the correct preprocessor and assembler are used > > for cross-builds the compilation is done in three stages. The target > > preprocessor specified at ./configure time is used to preprocess the > > %.i8 source; I8C consumes this preprocessed source and emits assembly > > language; and finally the target assembler specified at ./configure > > time is used to assemble the generated assembly language into object > > code. > > > > I don't *think* the %.o and %.os files should differ (they don't > > contain "real" code, just PT_NOTE sections) but please tell me if > > I'm wrong and I will add a separate %.S -> %.os rule. > > On some platforms the options passed to GCC when compiling a .S file > affect the options passed to the assembler, which in turn affects > the ELF header (this applies e.g. to MIPS passing -KPIC). So I > think you do need to compile the files separately. Ok, I will change this. > On some platforms, even assembler files with no actual code need to > contain certain assembler directives to be ABI-compatible with those > generated by the compiler. In particular, this applies to ARM; see > the .eabi_attribute directives in sysdeps/arm/sysdep.h. If > generating a .S file, you should make sure it includes <sysdep.h> so > that such directives are present. I did not know that. Is this because all glibc files include this file with the directives? (I guess what I'm asking is, in general, if I have a .c file and a .S file with no special directives, can I compile and link them and expect it to work?) For glibc is it ok if I add '-include sysdep.h' to the %.S -> %.o* rules? Thanks, Gary
On Wed, 21 Oct 2015, Gary Benson wrote: > > On some platforms, even assembler files with no actual code need to > > contain certain assembler directives to be ABI-compatible with those > > generated by the compiler. In particular, this applies to ARM; see > > the .eabi_attribute directives in sysdeps/arm/sysdep.h. If > > generating a .S file, you should make sure it includes <sysdep.h> so > > that such directives are present. > > I did not know that. Is this because all glibc files include this > file with the directives? Almost all .S files include <sysdep.h> to use its macros for defining functions etc. - and where they do not, special measures are needed on ARM (see sysdeps/arm/abi-note.S adding these attributes and then including csu/abi-note.S). Including <sysdep.h> in generated .S files is the simplest way of ensuring such directives are present when required. > (I guess what I'm asking is, in general, if I have a .c file and a > .S file with no special directives, can I compile and link them and > expect it to work?) Not without these directives on ARM. > For glibc is it ok if I add '-include sysdep.h' to the %.S -> %.o* > rules? I think that should work for these Infinity-generated files.
Joseph Myers wrote: > On Wed, 21 Oct 2015, Gary Benson wrote: > > Joseph Myers wrote: > > > On some platforms, even assembler files with no actual code need > > > to contain certain assembler directives to be ABI-compatible > > > with those generated by the compiler. In particular, this > > > applies to ARM; see the .eabi_attribute directives in > > > sysdeps/arm/sysdep.h. If generating a .S file, you should make > > > sure it includes <sysdep.h> so that such directives are present. > > > > I did not know that. Is this because all glibc files include this > > file with the directives? > > Almost all .S files include <sysdep.h> to use its macros for > defining functions etc. - and where they do not, special measures > are needed on ARM (see sysdeps/arm/abi-note.S adding these > attributes and then including csu/abi-note.S). Including <sysdep.h> > in generated .S files is the simplest way of ensuring such > directives are present when required. > > > (I guess what I'm asking is, in general, if I have a .c file and a > > .S file with no special directives, can I compile and link them > > and expect it to work?) > > Not without these directives on ARM. Yuck. Is there any generic way of obtaining the required directives for the host system? Can I obtain them from GCC somehow? I saw that sysdep.h doesn't get installed. I'll update Makerules to use '-include sysdep.h' to build for GLIBC because it may not be building for the host system, but I'm trying to figure out a way for standalone I8C to handle this properly (i.e. without emitting some kind of "#ifdef ARM..." boilerplate). Cheers, Gary
On Wed, 21 Oct 2015, Gary Benson wrote: > > Not without these directives on ARM. > > Yuck. Is there any generic way of obtaining the required directives > for the host system? Can I obtain them from GCC somehow? I saw that I don't think so (though the required directives on ARM are constant, not varying between the supported ABI variants). > sysdep.h doesn't get installed. Indeed, it's a glibc-internal header, not something providing any public interfaces.
Joseph Myers wrote: > On Wed, 21 Oct 2015, Gary Benson wrote: > > Joseph Myers wrote: > > > Not without these directives on ARM. > > > > Yuck. Is there any generic way of obtaining the required > > directives for the host system? Can I obtain them from GCC > > somehow? I saw that > > I don't think so (though the required directives on ARM are > constant, not varying between the supported ABI variants). I think I figured out a way of getting the stuff out of GCC. This command: echo -n | gcc -S -x c - -o - | grep -v '\.\(file\|ident\|section\)' gives me some useful-looking output on the only ARM box I have. So for standalone I8C I'll try doing something equivalent to generate the required directives. Probably a little hacky, but... For GLIBC I'll add an option to suppress the automatic preamble discovery and use -include to suck in sysdeps.h to make sure I'm getting it exactly right for whatever target is in use. Thanks for your help, Gary
diff --git a/Makerules b/Makerules index 1329f73..121b2b2 100644 --- a/Makerules +++ b/Makerules @@ -1510,6 +1510,22 @@ $(gpl2lgpl): %: $(..)gpl2lgpl.sed /home/gd/gnu/lib/% mv -f $@-tmp $@ endif endif + +$(objpfx)infinity-%.i8p: infinity-%.i8 + $(CPP) -x c $(CFLAGS) $(CPPFLAGS) $^ -o $@ + +$(objpfx)infinity-%.S: $(objpfx)infinity-%.i8p + $(I8C) -S -fpreprocessed $^ -o $@ + +$(objpfx)infinity-%.o: $(objpfx)infinity-%.S + $(CC) -c $(CFLAGS) $(CPPFLAGS) $^ -o $@ + +ifeq ($(build-shared),yes) +$(objpfx)infinity-%.os: $(objpfx)infinity-%.o + cp -f $^ $@ +endif + +.PRECIOUS: $(addprefix $(objpfx)infinity-%,.i8p .S .o) # Local Variables: # mode: makefile