Porting binutils to Amiga Unix

Porting binutils to Amiga Unix

[Mack Wallace]

I’m attempting to port binutils to Amiga Unix which is AT&T SVr4. I’m doing this because there are a few things I’d like to compile for which the native ld hangs as well as some pieces of software naturally recommend the gnu tools. However, I have some questions that I hope someone can help with. What I think I need help with is determining the emulation parameters: i.e. TEXT_START_ADDR, MAXPAGESIZE, NOP, etc. for ld? How do I go about determining these? More information regarding what I have and what I’m dealing with follows.

Here is what I have to work with:
AT&T Unix SVr4 on an Amiga with a 68030 processor, 16MB ram, 256MB swap.
Version 2.7.2.3 gcc compiler.
Version 2.2 libtool.

As this Unix is rather old, it does not have many c headers that are common today like stdint. I’m guessing this means it is either best / easiest to work with an earlier / early release of binutils.

If I try binutils version 2.8.1, it’s config.guess will recognize the canonical name of the machine m68k-cbm-sysv4. Later versions do not, simply returning m68k-unknown-sysv4, while the config.guess does recognize that it is an amiga and not amiga bsd. I presume dropping the canonical name was due to lack of interest or activity in development, and being designated m68k-unknown-sysv4 doesn’t affect much. In either case, while configuring ld, configure fails because "*** ld does not support target m68k-unknown-sysv4.”

So it looks like I need to setup something in configure.tgt to set targ_emul variable and then go from there.

My understanding has been that Amiga Unix uses the elf format for binaries. Looking at some binaries on the system, they begin with the magic number 7F. Wondering if the information I require could be gleaned by readelf, I downloaded the earliest copy of binutils that has that. I was able to compile readelf and its dependencies. Looking at some binaries, the “Entry Point Address” is something greater than 0x80000000 (I’ve seen addresses of 0x800000f94, 0x80000117c, 0x8000027d0). This is a guess, but using m68kelf.sh in emulparameters as a starting point: TEXT_START_ADDR=0x80000000? For both paged and non-paged?

If I run pagesize from the command prompt, I get a page size of 2048. So should I set my “MAXPAGESIZE” to 0x800? 

What should NOP be? In some emulation parameters, it’s not set at all.

Are there any other parameters that I should be setting?

Hope someone will be so kind as to provide some guidance. The porting guide that I looked at doesn’t seem to discuss the emulation parameters themselves.

I have continued trying to compile the rest of binutils. I have addr2line, ar, nm, objcopy, objdum, ranlib, readelf, size, strings, and strip compiled. Gas compiles but hangs during linking with AT&T ld. 

Regards,

Mack B Wallace

Re: Porting binutils to Amiga Unix

[Andreas Schwab]

On Feb 15 2017, Mack Wallace <mackbw@mapinternet.com> wrote:

> My understanding has been that Amiga Unix uses the elf format for
> binaries. Looking at some binaries on the system, they begin with the
> magic number 7F. Wondering if the information I require could be gleaned
> by readelf, I downloaded the earliest copy of binutils that has that. I
> was able to compile readelf and its dependencies. Looking at some
> binaries, the “Entry Point Address” is something greater than 0x80000000
> (I’ve seen addresses of 0x800000f94, 0x80000117c, 0x8000027d0). This is a
> guess, but using m68kelf.sh in emulparameters as a starting point:
> TEXT_START_ADDR=0x80000000? For both paged and non-paged?

I think you should be able to use m68kelf.sh unchanged.  It is also used
on m68k-linux, whose ELF support was based on SVr4 (with a few
peculiarities due to it's heritage which was based on the SunOS a.out
configuration).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Porting binutils to Amiga Unix

[Andreas Schwab]

On Feb 15 2017, Mack Wallace <mackbw@mapinternet.com> 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, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Porting binutils to Amiga Unix

[Mack Wallace]

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] */

#undef ASM_OUTPUT_ALIGNED_LOCAL
#define ASM_OUTPUT_ALIGNED_LOCAL(FILE, NAME, SIZE, ALIGN) 
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. */
#undef ASM_OUTPUT_ALIGNED_COMMON
/* Same problem with this one. */
#undef ASM_OUTPUT_ALIGNED_LOCAL

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. 

Regards,

Mack







> On Feb 16, 2017, at 4:52 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> 
> On Feb 15 2017, Mack Wallace <mackbw@mapinternet.com> 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, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> 

Re: Porting binutils to Amiga Unix

[Nick Clifton]

Hi Mack,

> compilation seems to error out on lines where there is a third argument to .lcomm. 

> So my question is, is the problem with by build of gnu as?

Yes and no, see below.

> Or is the problem with gcc building code with an alignment argument?

Well the simplest solution would be to omit the alignment argument.  Then you will
not have to make any changes to gnu as.

The GNU assembler does support a .lcomm directive with three arguments, but only
for certain targets.  Unfortunately the m68k is not one of these targets.  So in
order to fix your problem and have aligned entries in the .bss section you are 
going to have to modify the assembler sources.

Specifically you should find the definition of md_pseudo_table in gas/config/tc-m68k.c
and add entry that reads:

   { "lcomm", s_lcomm_bytes, 1 },
 
Assuming that you want the alignment parameter to be a power of two, or:

   { "lcomm", s_lcomm_bytes, 2 },
 
If you want the alignment power to be a number of bytes.  (Yes the sense of the
numbers is reversed.  No, I do not know why... :-)

Recompile and off you go.

BUT .. this would be a change that would affect all forms of the m68k assembler,
which would be a bad thing.  So either you need to protect this new definition with
a #ifdef ... #endif specific to the Amiga Unix port of the assembler, or else you
need to invent a new name for the pseudo-op and use that instead.  Or both.  For 
example:

#ifdef AMIGA_UNIX
   { "aligned_lcomm", s_lcomm_bytes, 1 },
 #endif

Of course if you use a new name, then you will have to update the definition of 
BSS_ASM_OP for gcc as well.

I hope that this makes sense.

Cheers
  Nick

Re: Porting binutils to Amiga Unix

[Maciej W. Rozycki]

On Tue, 11 Apr 2017, Nick Clifton wrote:

> The GNU assembler does support a .lcomm directive with three arguments, but only
> for certain targets.  Unfortunately the m68k is not one of these targets.  So in
> order to fix your problem and have aligned entries in the .bss section you are 
> going to have to modify the assembler sources.
> 
> Specifically you should find the definition of md_pseudo_table in gas/config/tc-m68k.c
> and add entry that reads:
> 
>    { "lcomm", s_lcomm_bytes, 1 },
>  
> Assuming that you want the alignment parameter to be a power of two, or:
> 
>    { "lcomm", s_lcomm_bytes, 2 },
>  
> If you want the alignment power to be a number of bytes.  (Yes the sense of the
> numbers is reversed.  No, I do not know why... :-)
> 
> Recompile and off you go.
> 
> BUT .. this would be a change that would affect all forms of the m68k assembler,
> which would be a bad thing.  So either you need to protect this new definition with
> a #ifdef ... #endif specific to the Amiga Unix port of the assembler, or else you
> need to invent a new name for the pseudo-op and use that instead.  Or both.  For 
> example:
> 
> #ifdef AMIGA_UNIX
>    { "aligned_lcomm", s_lcomm_bytes, 1 },
>  #endif

 Or, if necessary, you can handle the modified or new pseudo-op definition 
at the run time, like the MIPS target does in gas/config/tc-mips.c with 
`mips_nonecoff_pseudo_table'.

  Maciej