RE: GCC compile models -- theory of operation?
On Fri, 2007-08-03 at 15:58 +0100, Dave Korn wrote: > On 03 August 2007 15:48, Jonathan S. Shapiro wrote: > > > 2. Is there a simple way to configure the compiler so that the default > > compilation model (in the absence of command-line directives) is > > --static? If not, which of the various specfile macros need to be > > updated? I know how to write specfile lines, I just want to make sure > > that I don't miss one somewhere. > > > Just to address this one: I suggest using DRIVER_SELF_SPECS, since that runs > first of all, before anything else, and ensures that you will end up passing > consistent specs to all of the individual sub-executables without having to > worry that you could have missed one out somehow. Hmm. This is definitely not the type of answer I was expecting. Before I ask stupid questions, let me go read about this. Is DRIVER_SELF_SPECS documented somewhere? shap
GCC compile models -- theory of operation?
We're targeting a new OS with GCC. I've done some of these before, but
I've run into one issue I don't recognize, and a second that I have
obviously messed up. I have looked at "Using and Porting" and "GCC
Internals". The answers may be there, but I did not find them --
pointers welcome.
1. Versions of crtbegin
There are three versions of crtbegin: crtbegin.o, crtbeginS.o,
crtbeginT.o. 'S' is for shared/PIE -- I understand about that. Can
somebody explain what the distinction is between crtbeginT.o and
crtbegin.o?
2. Is there a simple way to configure the compiler so that the default
compilation model (in the absence of command-line directives) is
--static? If not, which of the various specfile macros need to be
updated? I know how to write specfile lines, I just want to make sure
that I don't miss one somewhere.
3. At least on i386, there are GOT sections appearing in
crt{begin,end}.o and libgcc.a. Our target does not have any dynamic
linking/loading support AT ALL. Are these sections fully resolved after
link time?
Thanks
Jonathan Shapiro
Re: ARM constant folding bug?
On Fri, 2007-08-03 at 12:46 -0400, Daniel Jacobowitz wrote: > On Fri, Aug 03, 2007 at 05:24:28PM +0100, Dave Korn wrote: > > I'm a bit surprised too. But it occurs to me that the ARM, unlike the > > i386 > > and m68k, is bi-endian. Perhaps you can't actually know which mode it's > > running in at compile time and /have/ to test it at runtime? > > No. You can't generate code in general that works on both! Then it seems very curious that the constant folding should fail on this platform. Any idea what may be going on here? shap
RE: ARM constant folding bug?
On Fri, 2007-08-03 at 17:24 +0100, Dave Korn wrote: > > I am not surprised that there is different behavior for different > > targets, but I am very surprised that *this* behavior is different. This > > optimization ought to be happening in the mid-end, and it ought to be > > entirely machine independent. > > I'm a bit surprised too. But it occurs to me that the ARM, unlike the i386 > and m68k, is bi-endian. Perhaps you can't actually know which mode it's > running in at compile time and /have/ to test it at runtime? That seems counter-intuitive, since a given compiler instance is configured for a target with a particular endian-ness. Even if the compiler can evade knowledge, the assembler surely must know. Of course, I am not running the assembler here. In any case, an interesting hypothesis. Would also explain some code pessimization issues for ARM targets more generally. shap
Link start address
This is probably a question that should be directed to the binutils list. We need to set the default link start address used by ld. Unfortunately ld doesn't have a nice porting guide like GCC does. :-) Actually, we need to choose one of two possible start addresses based on command line options to GCC, and I am wondering if this may make things more complicated. This is an ELF target. If we simply issue a --section-start for the .init section from GCC, will the other sections get adjusted accordingly under the generic linker script, or do we need to do something more involved? If it's more involved, where to look? Bother. I used to know how to do this. :-) shap
Re: GCC compile models -- theory of operation?
Ian: Thanks for the explanation of eh-frame-header. All of what you say makes sense. Before I dig in to this, is the eh-frame-header stuff documented somewhere? If so I should read that as well. shap
ARM constant folding bug?
This is observed on gcc-3.4.6. It may be a known issue, and/or it may be fixed in later compilers. For bringup purposes, I wrote an inline assembly hack to get the cross compiler to tell me whether the target is little/big endian. The code fragment is: const unsigned long ul = 0x04030201llu; if ( *((char *) &ul) == 0x1 ) ASMDEF(LITTLE_ENDIAN); else ASMDEF(BIG_ENDIAN); The expectation is that when run with -O2, the compiler should constant-fold all of this stuff away, resulting in exactly one ASMDEF. On i386 and m68k, the constant folding occurs as expected. For ARM it does not(!). I am not surprised that there is different behavior for different targets, but I am very surprised that *this* behavior is different. This optimization ought to be happening in the mid-end, and it ought to be entirely machine independent. Can somebody explain what is going on here? shap
Re: GCC compile models -- theory of operation?
First, thanks to Dave and Daniel for taking the time to reply. On Fri, 2007-08-03 at 11:06 -0400, Daniel Jacobowitz wrote: > crtbeginT.o is used for -static; crtbegin.o is used without -static. > I don't recall why they have to be different. So far as we can tell from looking at the linux versions, the only difference is that crtbeginT is calling register_frame_info_bases deregister_frame_info_bases I suspect that these are related to the exception frame walker, because if --static (therefore crtbeginT) is provided then --eh-frame-header is not applied by default. That is: I suspect that --static does not support exception frame walking. This smells like a Linux legacy issue that may not apply to us. Can anybody confirm or correct that guess? I think I need to understand the eh-frame support better. Where should I look for documentation on that? > > 2. Is there a simple way to configure the compiler so that the default > > compilation model (in the absence of command-line directives) is > > --static? If not, which of the various specfile macros need to be > > updated? I know how to write specfile lines, I just want to make sure > > that I don't miss one somewhere. > > Like Dave I recommend DRIVER_SELF_SPECS. Or you can just not put > shared libraries in your default linker search path; that's basically > equivalent. I can try this, and I'll look at the docs on that. > But it sounds like you are modelling after the wrong target, a Linux > one when you should be using an ELF one as base instead. You don't > need three CRT files or a separate -static option if you don't have > dynamic linking. And then you don't need to build libgcc with PIC > code in it, and there won't be GOT references any more. We are going to want to have the PIE and shared models later, so I don't want to disable those. At the moment all I am really trying to do is to get --static working correctly.
Re: ARM constant folding bug?
On Fri, 2007-08-03 at 10:34 -0700, Nathan Froyd wrote: > On Fri, Aug 03, 2007 at 06:24:06PM +0100, Paul Brook wrote: > > On Friday 03 August 2007, Jonathan S. Shapiro wrote: > > > Then it seems very curious that the constant folding should fail on this > > > platform. Any idea what may be going on here? > > > > You're exploiting a hole in the C aliasing rules by accessing a 32-bit int > > as > > type char. I tested several compilers (4.2, 4.1 and 3.4 x86, 4.2 m68k and > > 4.2 > > arm) and the only one that eliminated the comparison was 3.4-x86. > > FWIW, rewriting it with the "obvious" union approach seems to give the > desired results on 4.2 arm with and without -mbig-endian. Curiously, rewriting it with the "obvious" union approach didn't work at all on gcc-3.4.6. We're going to move forward go gcc-4.x anyway, but there are other priorities at the moment. shap
