headers
Masao Uebayashi | 13 Nov 2007 06:52
Picon
Gravatar

mips64eb's GNU_ARCH

Why mips64eb's GNU_ARCH is mips64, while that of mipseb is mipseb?

Masao
Permalink | Reply | 1 comment |
headers
Masao Uebayashi | 13 Nov 2007 07:03
Picon
Gravatar

SGI MIPSpro N32 assembler macros

According to "MIPSpro N32 ABI Handbook", they have macros which
support writing portable (== ABI-neutral) assembler code, like REG_L
and SETUP_GP.  src/sys/arch/mips/include/asm.h has some definitions
but it's very incomplete.

The question is, do we want the complete set of macros of SGI MIPSpro?
 If so, where can I find the (complete) reference?

Masao
Permalink | Reply | 1 comment |
headers
Masao Uebayashi | 13 Nov 2007 07:18
Picon
Gravatar

Toolchain and ABI

I want to use multiple ABI on NetBSD/mips platform.  I could configure
binutils / gcc (by running mknative) to handle the ABI I wanted.  That
part was fine.

According to Mattew Green, NetBSD toolchain can build output only in
the ABI that the toolchain is configured to handle by default.  For
example, if I configure mips64--netbsd-* to handle N32 by default, I
can create only N32 NetBSD binaries.  Of course, respective binutils /
gcc commands can handle multiple ABIs.  It is NetBSD source tree (make
file mostly) that can't switch ABI.

I'd want to hear the NetBSD solution to this problem.

Masao

P.S. I could make my local tree able to switch ABI by sprinkling extra
parameters to cc / as / ld in various make files.
Permalink | Reply | 0 comments |
headers
Masao Uebayashi | 13 Nov 2007 07:29
Picon
Gravatar

{REG,PTR}_{L,S} usage

I have many questions now. :)

I think REG_L / REG_R / PTR_L / PTR_S macros are used by the size of
the memory object size.  Is this correct?

For example, if I want to store a pointer (e.g. return address; which
is 32-bit on N32) into a call frame RA slot (which is register_t ==
64-bit on N32) on a stack, I should use REG_S, right?

Masao
Permalink | Reply | 1 comment |
headers
Simon Burge | 13 Nov 2007 07:35
Picon

Re: {REG,PTR}_{L,S} usage

"Masao Uebayashi" wrote:

> I have many questions now. :)
> 
> I think REG_L / REG_R / PTR_L / PTR_S macros are used by the size of
> the memory object size.  Is this correct?
> 
> For example, if I want to store a pointer (e.g. return address; which
> is 32-bit on N32) into a call frame RA slot (which is register_t ==
> 64-bit on N32) on a stack, I should use REG_S, right?

If you want to load/store a pointer, you use PTR_*.  If you're using n32
or o32 ABI, PTR_S will be "sw" and if you're using the n64 (or o64 if we
care about it) then PTR_S will be "sd".

You'd use REG_* if you know you want to deal with the full register.
One example that immediately jumps to mind is say setjmp()/longjmp().

Cheers,
Simon.
Permalink | Reply | 0 comments |
headers
Simon Burge | 13 Nov 2007 07:43
Picon

Re: SGI MIPSpro N32 assembler macros

"Masao Uebayashi" wrote:

> According to "MIPSpro N32 ABI Handbook", they have macros which
> support writing portable (== ABI-neutral) assembler code, like REG_L
> and SETUP_GP.  src/sys/arch/mips/include/asm.h has some definitions
> but it's very incomplete.
> 
> The question is, do we want the complete set of macros of SGI MIPSpro?
>  If so, where can I find the (complete) reference?

I think we do want the complete set of these macros.  The Linux
and Irix header files that define these are very similar but
not exactly the same - the macro names are the same but they're
reordered.

I don't think it should be too hard to cobble together something similar
for our <mips/asm.h> ...

Simon.
Permalink | Reply | 0 comments |
headers
Martin Husemann | 13 Nov 2007 11:01
Picon

Re: Toolchain and ABI

On Tue, Nov 13, 2007 at 03:18:25PM +0900, Masao Uebayashi wrote:
> I'd want to hear the NetBSD solution to this problem.

Me too!

I think there are three parts to the solution:

 - define a make variable to select abi, like ${TARGET_ABI}, and fix
   some of the share/mk files to provide proper CFLAGS/LDFLAGS depending
   on this being set
 - define new directories /lib${TARGET_ABI} and /usr/lib${TARGET_ABI}, and make
   /lib and /usr/lib a symlink to one of them. Make the mk files provide
   proper args for this, and/or modify gcc(1) and ld(1) to know about this
   abi dependend default directories.
 - modify the gcc/binutils configurations to supply multiple abis

Martin
Permalink | Reply | 0 comments |
headers
Simon Burge | 13 Nov 2007 11:08
Picon

Re: Toolchain and ABI

Martin Husemann wrote:

> On Tue, Nov 13, 2007 at 03:18:25PM +0900, Masao Uebayashi wrote:
> > I'd want to hear the NetBSD solution to this problem.
> 
> Me too!
> 
> I think there are three parts to the solution:
> 
>  [ ... ]
>  - modify the gcc/binutils configurations to supply multiple abis

At least for MIPS I'm pretty sure that gcc/binutils is always capable of
generating any of the required ABIs selectable by command line args, so
we don't need any changes there.

Simon.
Permalink | Reply | 0 comments |
headers
Masao Uebayashi | 13 Nov 2007 13:00
Picon
Gravatar

Re: Toolchain and ABI

> At least for MIPS I'm pretty sure that gcc/binutils is always capable of
> generating any of the required ABIs selectable by command line args, so
> we don't need any changes there.

I like passing command-line options to specify ABI too.

In this case those ABI options are mandatory unlike debug /
optimization / compiler check options which are used depending on user
preference.  In my local tree I created SYSCFLAGS / SYSAFLAGS /
SYSLDFLAGS and set ABI options there.

Masao
Permalink | Reply | 0 comments |
headers
Simon Burge | 13 Nov 2007 13:07
Picon

Re: Toolchain and ABI

"Masao Uebayashi" wrote:

> In this case those ABI options are mandatory unlike debug /
> optimization / compiler check options which are used depending on user
> preference.  In my local tree I created SYSCFLAGS / SYSAFLAGS /
> SYSLDFLAGS and set ABI options there.

This also gets us back to how you select a default ABI.  Does anyone
know what Irix does?  I'm not sure if we (NetBSD) should mandate a
default ABI or not.

Simon.
Permalink | Reply | 0 comments |

Gmane