i386-coff and i386-rtems problem

i386-coff and i386-rtems problem

[joel]

I don'y know why this just showed up now but it seems like a real problem.
The more complete problem report is blow my signature.  I think this patch
is equivalent to what is suggested.

$ diff -c i386-coff.h.orig i386-coff.h
*** i386-coff.h.orig    Mon Dec  7 12:35:10 1998
--- i386-coff.h Mon Dec  7 12:35:45 1998
***************
*** 93,97 ****
--- 93,106 ----
      fprintf (FILE, "\n");                                             \
    } while (0)
  
+ /*
+ This is how to output an assembler line   
+    that says to advance the location counter
+    to a multiple of 2**LOG bytes.
+ */
+ 
+ #undef ASM_OUTPUT_ALIGN
+ #define ASM_OUTPUT_ALIGN(FILE,LOG)      \
+     if ((LOG)!=0) fprintf ((FILE), "\t.align %d\n", 1<<(LOG))
  
  /* end of i386-coff.h */

 
--joel

Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985


---------- Forwarded message ----------
Date: Sun, 6 Dec 1998 18:22:35 -0600
From: Rosimildo da Silva <rdasilva@connecttel.com>
To: rtems <rtems-list@oarcorp.com>
Cc: joel@oarcorp.com
Subject: Re: RTEMS 4.0.0 and Standard PC - Problem Solved !!!!

I have figured out why the error, on the bottom of messages, happens when
you select the target i386-rtems to generate a cross compiler:

Environment:  Host: Win NT - Cygwin-b20;
                     Target: i386-rtems

This has been my first "warm" experience with GCC. So, it took me a couple
of days( and nights ), and
here is what I found to be the problem:

1. /build/egcs/gcc/tm.h ( target machine ) includes rtems.h
2. rtems.h includes i386-coff.h
3. i386-coff.h includes gas.h
4. gas.h includes i386.h
5. i386.h include 386bsd.h

i.e:    tm.h --> i386-coff.h --> gas.h --> i386.h  --> 386bsd.h

The problem is that the the definition of the macro ASM_OUTPUT_ALIGN is
coming form 386bsd.h in this chain, and it is defines as

/ *
    BSD/OS still uses old binutils that don't insert nops by default
    when the .align directive demands to insert extra space in the text
    segment.
*/
#undef ASM_OUTPUT_ALIGN
#define ASM_OUTPUT_ALIGN(FILE,LOG) \
  if ((LOG)!=0) fprintf ((FILE), "\t.align %d,0x90\n", (LOG))

I have noticed that it is very different from others i386 targets, such as
cygwin32.h, so I went to the end of
i386-coff.h and defined it as the one defined in cygwin32.h:

/*
This is how to output an assembler line
   that says to advance the location counter
   to a multiple of 2**LOG bytes.
*/

#undef ASM_OUTPUT_ALIGN
#define ASM_OUTPUT_ALIGN(FILE,LOG)	\
    if ((LOG)!=0) fprintf ((FILE), "\t.align %d\n", 1<<(LOG))

Doing this change I was able to compile the cross-compiler for the target
i386-rtems using Windows NT.

I have compiled and link a little test program( compiled + linked )
successfully.

Now that I have a cross compiler, I hope to start installing the RTEMS 4.0
environment in the next couple of days.

Hope this helps someone out there.

How do I log this for the GCC team to take care of it ?

Regards, Rosimildo.

============================================================================
=======
>>   if [ $? -eq 0 ] ; then true; else exit 1; fi; \
>>   i386-rtems-ar rc tmplibgcc2.a ${name}.o; \
>>   rm -f ${name}.o; \
>> done
>> _muldi3
>> _divdi3
>> _moddi3
>> _udivdi3
>> _umoddi3
>> _negdi2
>> _lshrdi3
>> _ashldi3
>> _ashrdi3
>> _ffsdi2
>> _udiv_w_sdiv
>> _udivmoddi4
>> _cmpdi2
>> _ucmpdi2
>> _floatdidf
>> D:\TEMP\ccyxok8Y.s: Assembler messages:
>> D:\TEMP\ccyxok8Y.s:112: Error: Alignment not a power of 2
>> make[1]: *** [libgcc2.a] Error 1
>> make: *** [cross] Error 2
>> bash-2.02$
>> bash-2.02$

Re: i386-coff and i386-rtems problem

[Jeffrey A Law]

  In message < Pine.LNX.3.96.981207104712.11167U-100000@oar3remote.oarcorp.com >y
ou write:
  > 
  > 
  > I don'y know why this just showed up now but it seems like a real problem.
  > The more complete problem report is blow my signature.  I think this patch
  > is equivalent to what is suggested.
I'd much rather see us figure out why the autoconf test for assembler
alignment features is not working properly.

I'd also like to see us use .balign and .palign since they are not
ambigious like .align is.

jeff

Re: i386-coff and i386-rtems problem

[joel]

On Tue, 8 Dec 1998, Jim Wilson wrote:

> In article <Pine.LNX.3.96.981207104712.11167U-100000.cygnus.egcs@oar3remote.oarcorp.com> you write:
> >>> _floatdidf
> >>> D:\TEMP\ccyxok8Y.s: Assembler messages:
> >>> D:\TEMP\ccyxok8Y.s:112: Error: Alignment not a power of 2
> 
> I've seen the same problem a few times.  I believe there is a bug in the
> configure tests that are used for HAVE_GAS_BALIGN_AND_P2ALIGN and
> HAVE_GAS_MAX_SKIP_P2ALIGN.  Sometimes the configure tests set these
> macros correctly, sometimes they don't.  If these macros are set incorrectly,
> then the error that you reported occurs.
> 
> I haven't determined exactly what the problem is yet.  However, if you
> look at the configure tests, there are 5 cases, but only the last two
> check to see if the macros should be set.  I think what happens is if
> ./as exists at the time you configure, then the macros don't get set,
> and the gcc build failures.  If you do a single-tree build, this won't be
> true at the initial configure, but it can be true on a reconfigure, causing
> builds to fail after a reconfigure.  It can also be true if you build
> and install gas before trying to build egcs, and then create a ./as link
> by hand.

I have never seen this problem under any unix flavor.  This problem report
occurred under Cygwin (which version I am not sure).  Perhaps the link
stuff is not working right.  Or "test" is not right.  I have seen cases
where the RTEMS test scripts did not work correctly due to odd problems in
Cygwin.  Sometimes they weren't even reliably reproducible.

This user was using my script to build the tools.  The script builds a
linked src/ directory and then does a configure, make, and make install.

I think Cygwin is not reliably grokking the test.

> >+ #undef ASM_OUTPUT_ALIGN
> >+ #define ASM_OUTPUT_ALIGN(FILE,LOG)      \
> >+     if ((LOG)!=0) fprintf ((FILE), "\t.align %d\n", 1<<(LOG))
> 
> This isn't safe in general, since not all i386 assemblers implement align
> the same way.  I think not even all versions of gas do it the same way.
> Hence it is safer to use balign/p2align instead of align if we can.
> It is probably safe enough for the i386-coff tm.h file though.

I can see this.  Could one of the Cygwin folks look at the autoconf tests
to see what might be failing?

--joel

Re: i386-coff and i386-rtems problem

[Jim Wilson]

In article <Pine.LNX.3.96.981207104712.11167U-100000.cygnus.egcs@oar3remote.oarcorp.com> you write:
>>> _floatdidf
>>> D:\TEMP\ccyxok8Y.s: Assembler messages:
>>> D:\TEMP\ccyxok8Y.s:112: Error: Alignment not a power of 2

I've seen the same problem a few times.  I believe there is a bug in the
configure tests that are used for HAVE_GAS_BALIGN_AND_P2ALIGN and
HAVE_GAS_MAX_SKIP_P2ALIGN.  Sometimes the configure tests set these
macros correctly, sometimes they don't.  If these macros are set incorrectly,
then the error that you reported occurs.

I haven't determined exactly what the problem is yet.  However, if you
look at the configure tests, there are 5 cases, but only the last two
check to see if the macros should be set.  I think what happens is if
./as exists at the time you configure, then the macros don't get set,
and the gcc build failures.  If you do a single-tree build, this won't be
true at the initial configure, but it can be true on a reconfigure, causing
builds to fail after a reconfigure.  It can also be true if you build
and install gas before trying to build egcs, and then create a ./as link
by hand.

>+ #undef ASM_OUTPUT_ALIGN
>+ #define ASM_OUTPUT_ALIGN(FILE,LOG)      \
>+     if ((LOG)!=0) fprintf ((FILE), "\t.align %d\n", 1<<(LOG))

This isn't safe in general, since not all i386 assemblers implement align
the same way.  I think not even all versions of gas do it the same way.
Hence it is safer to use balign/p2align instead of align if we can.
It is probably safe enough for the i386-coff tm.h file though.

Jim