This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Porting binutils to Amiga Unix

It has been a while, but I’ve also been testing and trying to build a version of gcc post ECGS on the Amiga.

I seem to have run into a hiccup which suggest, perhaps, I have a bit of cleanup with my port of binutils, specifically with gas.

While attempting to compile gcc, compilation seems to error out on lines where there is a third argument to .lcomm. 

The third argument seems to be specified by the platform specific amix.h file in the config/m68k subdirectory. The following is from that file:

/* This says how to output assembler code to declare an uninitialized internal linkage data object. Under SVR4, the linker seems to want the alignment of data objects to depend on their types. We do exactly that here. [This macro overrides the one in svr4.h because the amix assembler has a minimum default alignment of 4, and will not accept any explicit alignment smaller than this. -fnf] */

do { 
  fprintf ((FILE), “%s%s,%u,%u\n”,
           BSS_ASM_OP, (NAME), (SIZE), MAX ((ALLIGN) / BITS_PER_UNIT, 4)); 
} while {0}

BSS_ASM_OP is defined in m68kv4.h which is included by amix.h The following is noted from that file.

/* Local common symbols are declared to the assembler with “.lcomm” rather than  “.bss”, so override the definition in svr4.h*/
/* ??? svr4.h no longer defines this, and this is only used by m68k/amix.h. */
#undef BSS_ASM_OP
#define BSS_ASM_OP      “\t.lcomm\t”

Of course further on in the file, m68kv4.h, ASM_OUTPUT_ALIGNED_LOCAL is undefined. It mentions the following.
/* SVR4 m68k assembler is bitching on the `comm I,1,1’ which asks for 1 byte alignment. Don’t generate alignment for COMMON seems to be safer until we the assembler is fixed. */
/* Same problem with this one. */

Since amix.h includes m68kv4.h before it redefines ASM_OUTPUT_ALIGNED_LOCAL, I assume it’s definition is what stands.

Of course all of this appears to be for the AT&T assembler that came with the system, and not anticipating the use of gnu as. I am unfortunately not familiar with gnu assembly or m68k assembly, so I’m only going on what little I've read in the source files and online. 

>From what I’ve read, “some targets permit a third argument to be used with .lcomm. This argument specifies the desired alignment of the symbol in the bss section."

"For targets where the .lcomm directive does not accept and alignment argument, which is the case for most ELF targets, the .local directive …” (Amiga Unix uses ELF executables)- maybe why it wasn’t part of my gas build?)

If I remember correctly, someone wrote that gnu as may in some cases accept a third directive, but just ignores it. 

So my question is, is the problem with by build of gnu as? Or is the problem with gcc building code with an alignment argument?

If it is the former, how do I fix gnu as to allow for the third argument? If it doesn’t matter, should gas be fixed to allow, but ignore the third argument rather than erroring on code generated with the third argument? Or do I undef ASM_OUTPUT_ALIGNED_COMMON in the gcc build?

Hope someone has some wisdom they can impart. 



> On Feb 16, 2017, at 4:52 AM, Andreas Schwab <> wrote:
> On Feb 15 2017, Mack Wallace <> wrote:
>> If I run pagesize from the command prompt, I get a page size of 2048. So
>> should I set my “MAXPAGESIZE” to 0x800?
> For ELF, MAXPAGESIZE is defined by BFD, on m68k it is 0x2000 (see
> bfd/elf32-m68k.c).
> Andreas.
> -- 
> Andreas Schwab,
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]