[RFC,21/22] Add Makerules to build %.o and %.os from %.i8

  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(-)
  

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