freemint-discuss — The official FreeMiNT Mailing List

[Freemint-discuss] Ssystem( ) and ColdFire processors

[David G. <dga...@gm...>]

Hi,

while working on removing the M68040 machine flag for the ColdFire
build, I've found out that the Ssystem() system call (
http://toshyp.atari.org/en/00500e.html#Ssystem ) doesn't return
ColdFire information for the mode S_OSCOMPILE. This mode should return
the CPU type the kernel has been compiled for. Now a ColdFire kernel
returns 68040. I'd like to add the right ColdFire information.

The value returned is a 32 bit number which encodes the information like this:

0-7 Binary minor CPU ID
8-15 Binary major CPU ID
16-31 Reserved for future definition

The major CPU ID now only returns a 0x00 value and means m68k family.

1) First question. Should the ColdFire be included in this family or
should we add 0x01 value for the ColdFire family?

Here I'm for adding a new family.

The minor CPU ID means the exact CPU and the values are:

0x00 68000
0x0a 68010
0x14 68020
0x1e 68030
0x28 68040
0x3c 68060

Now the kernel returns values for the 68000, 68030, 68040 and the 68060

2) Second question. Which information do we give for the ColdFire processors?.

We can give:
a) the ISA classification (isaa, isab, isac, etc...).
b) the CPU names as given in the "-mcpu=" option in GCC (52xx, 53xx, 54xx, etc).
c) what it's called as micro-architecture by GCC (cfv1, cfv2, cfv3, cfv4, etc).

I'm for the ISA option but I don't have a strong opinion about it.

Later we should decide how this info is shown, it's not going to be
possible to be consistent with how it's done for the 680x0 family.

Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

[Markus F. <mf...@mu...>]

Note that FreeMiNT works fine on other ColdFire boards (like the M5484
Evaluation Board) as well.

It's just that it never found its way into the Makefile as specific
target but requires manual fiddling with CONFIGVARS.


Am 21.04.2018 um 19:00 schrieb Thorsten Otto:
> On Samstag, 21. April 2018 18:25:19 CEST Vincent Rivière wrote:
>> .e. TARGET_512, TARGET_FIREBEE, etc.
>>
>> Could become TARGET_000, TARGET_V4E in FreeMiNT.
>> Verbose, but no possible confusion.
> TARGET_FIREBEE makes sense in EmuTOS, to distinguish it from other bare-metal 
> coldfire targets. But for Mint there is only one such target IIRC. If needed, 
> we should use TARGET_FIREBEE too there, but TARGET_V4E does not make much 
> sense, as you can use the already existing macros when you need to know the 
> target processor.
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>

Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

[Thorsten O. <ad...@th...>]

On Samstag, 21. April 2018 18:54:34 CEST David Gálvez wrote:
> I've noticed a variation of this issue, where there is a check for the

As for the unaligned_putl function: that seems to be only used in very few 
cases, and not in speed-critical code, so maybe that ifdef, and the check for 
odd address can be removed there completely, and just use always the safe 
code.

For the other cases, the check has to be changed.

Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

[Thorsten O. <ad...@th...>]

On Samstag, 21. April 2018 18:33:57 CEST David Gálvez wrote:
> I
> think that the -D68000 when compiling MINT020.PRG should be removed,

IIRC there were some early checks whether the detected cpu actually matches 
the way the kernel was compiled (but i'm not sure wether that really ever 
worked, it might be already too late when some code compiled with -m68020 is 
executed on plain m68000; that would require to ensure that all code up to 
that point really runs on all machines, including coldfire, and you can't use  
kprintf() or similar to diagnose the problem since that will again might use 
code for a wrong processor).

Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

[Thorsten O. <ad...@th...>]

On Samstag, 21. April 2018 18:25:19 CEST Vincent Rivière wrote:
> .e. TARGET_512, TARGET_FIREBEE, etc.
> 
> Could become TARGET_000, TARGET_V4E in FreeMiNT.
> Verbose, but no possible confusion.

TARGET_FIREBEE makes sense in EmuTOS, to distinguish it from other bare-metal 
coldfire targets. But for Mint there is only one such target IIRC. If needed, 
we should use TARGET_FIREBEE too there, but TARGET_V4E does not make much 
sense, as you can use the already existing macros when you need to know the 
target processor.

Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

[David G. <dga...@gm...>]

2018-04-21 17:36 GMT+02:00 Thorsten Otto <ad...@th...>:
> I think i already mentioned this, but you just have to keep in mind that -
> m68020-60 will define all macros from __mc68020__ upto __mc68060__, while -
> m68060 will *only* define __mc68060__, so there might be places that currently
> test for __mc68020__ only, where they actually want to know whether 68020 and
> above instructions can be used, and thus have to be changed to test for any of
> the macros.

I've noticed a variation of this issue, where there is a check for the
68000 with __mc68000__ or mc68000 and there will be "false positives"
when compiling for the 68020 and above:

https://github.com/freemint/freemint/blob/76262f82c1594aa0c59ee72803824924daf6026c/sys/libkern/unaligned.c#L35

https://github.com/freemint/freemint/blob/76262f82c1594aa0c59ee72803824924daf6026c/sys/libkern/asm/quickmove.S#L49

https://github.com/freemint/freemint/blob/76262f82c1594aa0c59ee72803824924daf6026c/tools/crypto/crypt.c#L135

Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

[David G. <dga...@gm...>]

2018-04-21 17:36 GMT+02:00 Thorsten Otto <ad...@th...>:
> On Samstag, 21. April 2018 17:15:38 CEST David Gálvez wrote:
>> I'm thinking about creating the machine flag "COLDFIRE" in KERNELDEFS,
>> add it in the sources wherever the M68040 macro is used and then
>> remove the -DM68040 flag when compiling the MINTV4E.PRG.
>
> It might depend. As Vincent pointed out, if you are using the same compiler
> flags for different targets, then you have to use some define in the Makefile
> (but i would prefer something else than M68000 since that might clash again).
> When it comes to distinguish between whether you can use code for a specific
> processor, you are better off using the compiler defined macros like
> __mcoldfire__. No need to add a separate define for this in the Makefile, that
> will makes things just more complicated than necessary, and again add
> confusion which macro to test.
>

OK I see, then I'll add __mcoldfire__ checks wherever M68040 is used,
remove -D68040 flag in MINTV4E.PRG build flags. and I won't create a
new COLDFIRE flag if it's not necessary.

> I think i already mentioned this, but you just have to keep in mind that -
> m68020-60 will define all macros from __mc68020__ upto __mc68060__, while -
> m68060 will *only* define __mc68060__, so there might be places that currently
> test for __mc68020__ only, where they actually want to know whether 68020 and
> above instructions can be used, and thus have to be changed to test for any of
> the macros.
>

Yes I think you did but I got confused by the old  __M680x0__  macro
behavior. Fortunately there aren't to many instances where __mc68020__
is used, the ones that I swapped in the commit and I've seen one in
the ext2 code that should be corrected for sure.

> But setting up the Makefile to use something like -mc68020 -DM68020 is imho
> confusing, and again you will have a mix of tests.

At the end creating the M68020 machine flag isn't necessary but I
think that the -D68000 when compiling MINT020.PRG should be removed,
I've searched for the commit where this was added and there is no
explanation about why -D68000 is needed in the 68020 kernels.

Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

[Vincent R. <vin...@fr...>]

On 21/04/2018 at 17:36, Thorsten Otto wrote:
> It might depend. As Vincent pointed out, if you are using the same compiler
> flags for different targets, then you have to use some define in the Makefile
> (but i would prefer something else than M68000 since that might clash again).

I completely agree.
In EmuTOS, I have chosen verbose defines based on the Makefile target name.
i.e. TARGET_512, TARGET_FIREBEE, etc.

Could become TARGET_000, TARGET_V4E in FreeMiNT.
Verbose, but no possible confusion.

-- 
Vincent Rivière

Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

[Thorsten O. <ad...@th...>]

On Samstag, 21. April 2018 17:15:38 CEST David Gálvez wrote:
> I'm thinking about creating the machine flag "COLDFIRE" in KERNELDEFS,
> add it in the sources wherever the M68040 macro is used and then
> remove the -DM68040 flag when compiling the MINTV4E.PRG.

It might depend. As Vincent pointed out, if you are using the same compiler 
flags for different targets, then you have to use some define in the Makefile 
(but i would prefer something else than M68000 since that might clash again). 
When it comes to distinguish between whether you can use code for a specific 
processor, you are better off using the compiler defined macros like 
__mcoldfire__. No need to add a separate define for this in the Makefile, that 
will makes things just more complicated than necessary, and again add 
confusion which macro to test.

I think i already mentioned this, but you just have to keep in mind that -
m68020-60 will define all macros from __mc68020__ upto __mc68060__, while -
m68060 will *only* define __mc68060__, so there might be places that currently 
test for __mc68020__ only, where they actually want to know whether 68020 and 
above instructions can be used, and thus have to be changed to test for any of 
the macros.

But setting up the Makefile to use something like -mc68020 -DM68020 is imho 
confusing, and again you will have a mix of tests.

Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

[Vincent R. <vin...@fr...>]

On 21/04/2018 at 17:15, David Gálvez wrote:
> I'm thinking about creating the machine flag "COLDFIRE" in KERNELDEFS,
> add it in the sources wherever the M68040 macro is used and then
> remove the -DM68040 flag when compiling the MINTV4E.PRG.

Exactly the thing to do.
I planned to do that, but was too shy...

-- 
Vincent Rivière

Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

[David G. <dga...@gm...>]

2018-04-21 16:58 GMT+02:00 Vincent Rivière <vin...@fr...>:
> On 21/04/2018 at 16:53, David Gálvez wrote:
>>
>> "#if !(defined(M68000) || defined(__mcoldfire__))")
>
>
> IIRC (not sure):
>
> - defined(M68000) means: "we are building the MINT000.PRG"
> - defined(__mcoldfire__) means: "we are building the MINTV4E.PRG" (as we
> don't have a specific define)
>
> A specific define can be useful when building several kernels with the same
> CPU options (which definitely happens in EmuTOS).
>

I'm thinking about creating the machine flag "COLDFIRE" in KERNELDEFS,
add it in the sources wherever the M68040 macro is used and then
remove the -DM68040 flag when compiling the MINTV4E.PRG.

Also I have seen that when compiling MINT020.PRG, the -D68000 flag is
used, this seems wrong to me. I think about creating the M68020
machine flag too that is missing now.

Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

[Vincent R. <vin...@fr...>]

On 21/04/2018 at 16:53, David Gálvez wrote:
> "#if !(defined(M68000) || defined(__mcoldfire__))")

IIRC (not sure):

- defined(M68000) means: "we are building the MINT000.PRG"
- defined(__mcoldfire__) means: "we are building the MINTV4E.PRG" (as we 
don't have a specific define)

A specific define can be useful when building several kernels with the same 
CPU options (which definitely happens in EmuTOS).

-- 
Vincent Rivière

Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

[David G. <dga...@gm...>]

2018-03-22 13:50 GMT+01:00 David Gálvez <dga...@gm...>:
> 2018-02-19 10:02 GMT+01:00 David Gálvez <dga...@gm...>:
>> 2018-02-19 9:45 GMT+01:00 David Gálvez <dga...@gm...>:
>>> Move this discussion from github to the list.
>>>
>>> So if I understand correctly __M680x0__ (with uppercase) is MiNT's
>>> specific and it's deprecated, I've seen 7 use instances in the
>>> kernel's code, by coincidence 4 in files I'm working with right now,
>>> then the alternative is the compiler general  __mc680x0__ (with lower
>>> case), but it's still no clear to me what is state of these macros in
>>> gcc 7. Can use them safely?
>>>
>>>
>>
>> I have just read this in the gcc 7.3.0 manual:
>>
>> "GCC defines the macros __mcarch and __mcarch__ when tuning for 680x0
>> architecture arch. It also defines mcarch unless either -ansi or a
>> non-GNU -std option is used. If GCC is tuning for a range of
>> architectures, as selected by -mtune=68020-40 or -mtune=68020-60, it
>> defines the macros for every architecture in the range."
>>
>> So  in theory it's safe and nothing has been changed regarding these
>> macros between compiler's version.
>>
>> I'm going to remove what is left of the uppercase macros and swap them
>> by the lowercase ones
>>
>
> I've now replaced the old MiNT's specific macros by the generic ones.
> I've left untouched the M680x0 macros (without underscores) that are
> defined during the compile's time (see KERNELDEFS).
> Those seems to have some extra purpose, for example the macro M68040
> is defined when compiling the ColdFire kernel.
>
> Still there are some defines that mix both macros types (like this one
>  "#if !(defined(M68000) || defined(__mcoldfire__))")
> https://github.com/freemint/freemint/blob/1196c6f665b6eed314b419ce560f445ebaeae5a1/sys/arch/intr.S#L749
> If this is not on purpose we could replace them too for code consistency.

The commit broke things. When compiling with -m68060 the __M68020__
macro is defined but not the __mc68020__, so replace one for the other
wasn't a good idea.
Now to fix this I have doubts if using the M680x0 macros (without
underscores) defined in KERNELDEFS or the ones defined by the
compiler.

Re: [Freemint-discuss] Struct ucontext_t

[David G. <dga...@gm...>]

2018-04-19 11:15 GMT+02:00 Thorsten Otto <ad...@th...>:
> On Donnerstag, 19. April 2018 10:10:33 CEST David Gálvez wrote:
>> I've seen that sigmask is in a different position only in Linux-m68k
>> kernel headers files, but in glibc and NetBSD
>> is in the same location than in MiNTlib:
>
> But the installed header file is machine dependent (it's a copy of  sysdeps/
> unix/sysv/linux/{arch}/sys/ucontext.h from the source archive), and the one
> you are quoting there is not the one used for linux/m68k.
>

Yes, you're right, I missed the Linux specific ucontext.h file in the
GNU C lib sources.
The one I linked here it was machine dependent too
"sysdeps/m68k/sys/ucontext.h",
but of course not what the glibc is installing in Linux-m68k.
I've also seen that the "generic" glibc ucontext struct in
"sysdeps/generic/sys" also
moved the sigmask to the end of the struct.

>>Do you have in mind an example
>>of a possible situation where having the registers
>>in different positions in the struct would affect portability.
>
> My goal would be to actually implement that functionality, both in the library
> and in the kernel. Actually i think it does not matter much how the structure
> is actually implemented, but it would make sense to use the same structure for
> both, so that the library does not have to make a copy of it. And for that it
> should be defined in a way that future enhancements are easier (e.g. more than
> 32 signals numbers).
>

I think that makes sense.

Re: [Freemint-discuss] Struct ucontext_t

[Thorsten O. <ad...@th...>]

On Donnerstag, 19. April 2018 10:10:33 CEST David Gálvez wrote:
> I've seen that sigmask is in a different position only in Linux-m68k
> kernel headers files, but in glibc and NetBSD
> is in the same location than in MiNTlib:

But the installed header file is machine dependent (it's a copy of  sysdeps/
unix/sysv/linux/{arch}/sys/ucontext.h from the source archive), and the one 
you are quoting there is not the one used for linux/m68k.

>My guess is that portable software is using glibc instead the Linux
>kernel headers file.

Well that structure isn't really portable. And IIRC correctly its not even 
defined in kernel headers.

Given that the functions aren't implement in Mintlib, and that the kernel does 
not pass the information to signal handlers, it is unlikely that any existing 
software for MiNT makes use of that structure. 

>Do you have in mind an example
>of a possible situation where having the registers
>in different positions in the struct would affect portability.

My goal would be to actually implement that functionality, both in the library 
and in the kernel. Actually i think it does not matter much how the structure 
is actually implemented, but it would make sense to use the same structure for 
both, so that the library does not have to make a copy of it. And for that it 
should be defined in a way that future enhancements are easier (e.g. more than 
32 signals numbers).

>"POSIX.1-2004 obsoleted these functions, and in POSIX.1-2008 they were
>removed, with POSIX Threads indicated as a possible replacement"

... the only problem being that there is no such thing as a posix-compliant 
thread library for mint, which is a  really stopper for a lot of modern 
applications. A lot of them don't even compile when pthread.h is not 
available.

Re: [Freemint-discuss] Struct ucontext_t

[David G. <dga...@gm...>]

Hi Thorsten, I did some research about this, below what I've found out.

2018-04-07 16:25 GMT+02:00 Thorsten Otto <ad...@th...>:
> While experimenting with some code, i noticed that our struct ucontext in sys/
> ucontext_h is similar, but not identical to the one from linux/m68k.
>
> The main differences are that, in the general registers, R_PC/R_PS (i think
> that should be the status register?) are reversed, the sigmask is at a
> different location (maybe because on linux a complete set it is more than just
> a long), and the layout of the floating point register set is different. Would
> it be a problem to reorder them? That could make porting some software much
> easier. As far as i can tell, although that structure is defined, it is
> nowhere used: {get,set,make,swap}context are not implemented, and SA_SIGINFO
> isn't either.
>

I've seen that sigmask is in a different position only in Linux-m68k
kernel headers files, but in glibc and NetBSD
is in the same location than in MiNTlib:

glibc:

 /* Userlevel context.  */
  typedef struct ucontext_t
  {
    unsigned long int __ctx(uc_flags);
    struct ucontext_t *uc_link;
    sigset_t uc_sigmask;
    stack_t uc_stack;
    mcontext_t uc_mcontext;
    long int __glibc_reserved1[201];
  } ucontext_t;

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/m68k/sys/ucontext.h;h=14232d268ae7147239bfb7c4c9681036240e8d0b;hb=f55a4fdefb00837f2e2a77c04792e69e888ead3e#l112

NetBSD:

typedef struct __ucontext ucontext_t;

struct __ucontext {
    unsigned int uc_flags; /* properties */
    ucontext_t * uc_link; /* context to resume */
    sigset_t uc_sigmask; /* signals blocked in this context */
    stack_t uc_stack; /* the stack used by this context */
    mcontext_t uc_mcontext; /* machine state */
#if defined(_UC_MACHINE_PAD)
    long __uc_pad[_UC_MACHINE_PAD];
#endif
};

https://github.com/NetBSD/src/blob/4a985cb82ed80063a586ae42790a829e2ec7a59b/sys/sys/ucontext.h#L38

My guess is that portable software is using glibc instead the Linux
kernel headers file.
So I wouldn't change anything regarding the sigmask position in the
ucontext struct.

The PC and PS registers are switched in MiNTlib in relation with glibc
and NetBSD,
also fpregset differs in MiNTlib from glibc and NetBSD but I've found
this in the GNU C lib documentation:

"mcontext_t uc_mcontext

This element contains the actual state of the process. The mcontext_t
type is also defined in this header but
the definition should be treated as opaque. Any use of knowledge of
the type makes applications less portable."

http://www.gnu.org/software/libc/manual/html_node/System-V-contexts.html

So I think I wouldn't change anything. Do you have in mind an example
of a possible situation where having the registers
in different positions in the struct would affect portability.

By the way as a curiosity during my research I've read that all these
things are deprecated in the POSIX specification:
"POSIX.1-2004 obsoleted these functions, and in POSIX.1-2008 they were
removed, with POSIX Threads indicated as a possible replacement"

Re: [Freemint-discuss] Bad news: a.out support for m68k is going to be removed from binutils

[Thorsten O. <ad...@th...>]

On Montag, 16. April 2018 15:33:24 CEST Mark Duckworth wrote:
> But why?  Is this is because they think nobody uses it or because it is
> holding back the binutils codebase?  If the former, we could push to
> keep it.

I think this is because nobody at FSF actively maintains it. And of course it 
is more work when doing general code changes that affect all targets. There 
was a question about this removal about a year ago already, now it has come 
true :(

As long as only binutils is affected, this not a real problem for us i think. 
It is unlikely that any new features are ported to a.out anyway, so we can 
just stick to the current (2.30) version. It will only become a problem if the 
compiler starts to spit out mnemonics that our assembler does not understand.

Another possibility is to add the removed parts back in our patch, as for now 
that should not be a big deal (we don't have to care about coff, or parts 
specific to other hosts; also the patches for the testsuite could be omitted 
since that part can never be run by a cross-compiler, and i think that it has 
not been run for a long time on real hardware.

Re: [Freemint-discuss] Bad news: a.out support for m68k is going to be removed from binutils

[Mark D. <mdu...@at...>]

But why?  Is this is because they think nobody uses it or because it is
holding back the binutils codebase?  If the former, we could push to
keep it.

Thanks,

Mark



On 04/16/2018 05:23 AM, Thorsten Otto wrote:
> As seen on the binutils mailing list:
>
> ----------  Forwarded Message  ----------
>
> Subject: Remove m68k-aout and m68k-coff support
> Date: Montag, 16. April 2018, 08:24:46 CEST
> From: Alan Modra <am...@gm...>
> To: bin...@so...
>
> include/
> 	* aout/host.h: Remove m68k-aout and m68k-coff support.
> 	* aout/hp300hpux.h: Delete.
> 	* coff/apollo.h: Delete.
> 	* coff/aux-coff.h: Delete.
> 	* coff/m68k.h: Delete.
> bfd/
> 	* Makefile.am: Remove m68k-aout and m68k-coff support.
> 	* aoutf1.h: Likewise.
> 	* aoutx.h: Likewise.
> 	* archive.c: Likewise.
> 	* bfd-in.h: Likewise.
> 	* bfd.c: Likewise.
> 	* coffcode.h: Likewise.
> 	* coffswap.h: Likewise.
> 	* config.bfd: Likewise.
> 	* configure.ac: Likewise.
> 	* configure.host: Likewise.
> 	* doc/bfd.texinfo: Likewise.
> 	* doc/bfdint.texi: Likewise.
> 	* freebsd.h: Likewise.
> 	* gen-aout.c: Likewise.
> 	* hpux-core.c: Likewise.
> 	* libaout.h: Likewise.
> 	* libbfd-in.h: Likewise.
> 	* pdp11.c: Likewise.
> 	* peicode.h: Likewise.
> 	* riscix.c: Likewise.
> 	* targets.c: Likewise.
> 	* aout0.c: Delete.
> 	* coff-apollo.c: Delete.
> 	* coff-aux.c: Delete.
> 	* coff-m68k.c: Delete.
> 	* coff-svm68k.c: Delete.
> 	* coff-u68k.c: Delete.
> 	* hosts/delta68.h: Delete.
> 	* hosts/hp300bsd.h: Delete.
> 	* hosts/m68kaux.h: Delete.
> 	* hosts/news.h: Delete.
> 	* hp300bsd.c: Delete.
> 	* hp300hpux.c: Delete.
> 	* liboasys.h: Delete.
> 	* m68k4knetbsd.c: Delete.
> 	* m68klinux.c: Delete.
> 	* m68knetbsd.c: Delete.
> 	* oasys.c: Delete.
> 	* versados.c: Delete.
> 	* Makefile.in: Regenerate.
> 	* bfd-in2.h: Regenerate.
> 	* configure: Regenerate.
> 	* libbfd.h: Regenerate.
> 	* po/SRC-POTFILES.in: Regenerate.
> binutils/
> 	* testsuite/binutils-all/copy-2.d: Remove m68k-aout and m68k-coff
> 	support.
> 	* testsuite/binutils-all/copy-3.d: Likewise.
> 	* testsuite/binutils-all/objcopy.exp: Likewise.
> 	* testsuite/lib/binutils-common.exp: Likewise.
> gas/
> 	* Makefile.am: Remove m68k-aout and m68k-coff support.
> 	* config/tc-m68k.c: Likewise.
> 	* config/tc-m68k.h: Likewise.
> 	* configure.ac: Likewise.
> 	* configure.tgt: Likewise.
> 	* testsuite/gas/all/weakref1u.d: Likewise.
> 	* testsuite/gas/m68k/all.exp: Likewise.
> 	* testsuite/gas/m68k/br-isaa.d: Likewise.
> 	* testsuite/gas/m68k/br-isab.d: Likewise.
> 	* testsuite/gas/m68k/br-isac.d: Likewise.
> 	* config/te-psos.h: Delete.
> 	* config/te-sun3.h: Delete.
> 	* testsuite/gas/m68k-coff/gas.exp: Delete.
> 	* testsuite/gas/m68k-coff/p2389.s: Delete.
> 	* testsuite/gas/m68k-coff/p2389a.s: Delete.
> 	* testsuite/gas/m68k-coff/p2430.s: Delete.
> 	* testsuite/gas/m68k-coff/p2430a.s: Delete.
> 	* testsuite/gas/m68k-coff/t1.s: Delete.
> 	* testsuite/gas/m68k/p3041.d: Delete.
> 	* testsuite/gas/m68k/p3041.s: Delete.
> 	* testsuite/gas/m68k/p3041data.d: Delete.
> 	* testsuite/gas/m68k/p3041data.s: Delete.
> 	* testsuite/gas/m68k/p3041pcrel.d: Delete.
> 	* testsuite/gas/m68k/p3041pcrel.s: Delete.
> 	* testsuite/gas/m68k/t2.d: Delete.
> 	* Makefile.in: Regenerate.
> 	* config.in: Regenerate.
> 	* configure: Regenerate.
> 	* po/POTFILES.in: Regenerate.
> ld/
> 	* Makefile.am: Remove m68k-aout and m68k-coff support.
> 	* configure.tgt: Likewise.
> 	* emultempl/m68kelf.em: Likewise.
> 	* ld.texinfo: Likewise.
> 	* mri.c: Likewise.
> 	* emulparams/delta68.sh: Delete.
> 	* emulparams/hp300bsd.sh: Delete.
> 	* emulparams/hp3hpux.sh: Delete.
> 	* emulparams/m68k4knbsd.sh: Delete.
> 	* emulparams/m68kaout.sh: Delete.
> 	* emulparams/m68kaux.sh: Delete.
> 	* emulparams/m68kcoff.sh: Delete.
> 	* emulparams/m68klinux.sh: Delete.
> 	* emulparams/m68knbsd.sh: Delete.
> 	* emulparams/m68kpsos.sh: Delete.
> 	* emulparams/sun3.sh: Delete.
> 	* emultempl/m68kcoff.em: Delete.
> 	* scripttempl/delta68.sc: Delete.
> 	* scripttempl/m68kaux.sc: Delete.
> 	* scripttempl/m68kcoff.sc: Delete.
> 	* scripttempl/psos.sc: Delete.
> 	* testsuite/ld-versados/t1-1.ro: Delete.
> 	* testsuite/ld-versados/t1-2.ro: Delete.
> 	* testsuite/ld-versados/t1.ld: Delete.
> 	* testsuite/ld-versados/t1.ook: Delete.
> 	* testsuite/ld-versados/t2-1.ro: Delete.
> 	* testsuite/ld-versados/t2-2.ro: Delete.
> 	* testsuite/ld-versados/t2-3.ro: Delete.
> 	* testsuite/ld-versados/t2.ld: Delete.
> 	* testsuite/ld-versados/t2.ook: Delete.
> 	* testsuite/ld-versados/versados.exp: Delete.
> 	* Makefile.in: Regenerate.
> 	* po/BLD-POTFILES.in: Regenerate.
>
> Alan Modra
> Australia Development Lab, IBM
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

[Freemint-discuss] Bad news: a.out support for m68k is going to be removed from binutils

[Thorsten O. <ad...@th...>]

As seen on the binutils mailing list:

----------  Forwarded Message  ----------

Subject: Remove m68k-aout and m68k-coff support
Date: Montag, 16. April 2018, 08:24:46 CEST
From: Alan Modra <am...@gm...>
To: bin...@so...

include/
	* aout/host.h: Remove m68k-aout and m68k-coff support.
	* aout/hp300hpux.h: Delete.
	* coff/apollo.h: Delete.
	* coff/aux-coff.h: Delete.
	* coff/m68k.h: Delete.
bfd/
	* Makefile.am: Remove m68k-aout and m68k-coff support.
	* aoutf1.h: Likewise.
	* aoutx.h: Likewise.
	* archive.c: Likewise.
	* bfd-in.h: Likewise.
	* bfd.c: Likewise.
	* coffcode.h: Likewise.
	* coffswap.h: Likewise.
	* config.bfd: Likewise.
	* configure.ac: Likewise.
	* configure.host: Likewise.
	* doc/bfd.texinfo: Likewise.
	* doc/bfdint.texi: Likewise.
	* freebsd.h: Likewise.
	* gen-aout.c: Likewise.
	* hpux-core.c: Likewise.
	* libaout.h: Likewise.
	* libbfd-in.h: Likewise.
	* pdp11.c: Likewise.
	* peicode.h: Likewise.
	* riscix.c: Likewise.
	* targets.c: Likewise.
	* aout0.c: Delete.
	* coff-apollo.c: Delete.
	* coff-aux.c: Delete.
	* coff-m68k.c: Delete.
	* coff-svm68k.c: Delete.
	* coff-u68k.c: Delete.
	* hosts/delta68.h: Delete.
	* hosts/hp300bsd.h: Delete.
	* hosts/m68kaux.h: Delete.
	* hosts/news.h: Delete.
	* hp300bsd.c: Delete.
	* hp300hpux.c: Delete.
	* liboasys.h: Delete.
	* m68k4knetbsd.c: Delete.
	* m68klinux.c: Delete.
	* m68knetbsd.c: Delete.
	* oasys.c: Delete.
	* versados.c: Delete.
	* Makefile.in: Regenerate.
	* bfd-in2.h: Regenerate.
	* configure: Regenerate.
	* libbfd.h: Regenerate.
	* po/SRC-POTFILES.in: Regenerate.
binutils/
	* testsuite/binutils-all/copy-2.d: Remove m68k-aout and m68k-coff
	support.
	* testsuite/binutils-all/copy-3.d: Likewise.
	* testsuite/binutils-all/objcopy.exp: Likewise.
	* testsuite/lib/binutils-common.exp: Likewise.
gas/
	* Makefile.am: Remove m68k-aout and m68k-coff support.
	* config/tc-m68k.c: Likewise.
	* config/tc-m68k.h: Likewise.
	* configure.ac: Likewise.
	* configure.tgt: Likewise.
	* testsuite/gas/all/weakref1u.d: Likewise.
	* testsuite/gas/m68k/all.exp: Likewise.
	* testsuite/gas/m68k/br-isaa.d: Likewise.
	* testsuite/gas/m68k/br-isab.d: Likewise.
	* testsuite/gas/m68k/br-isac.d: Likewise.
	* config/te-psos.h: Delete.
	* config/te-sun3.h: Delete.
	* testsuite/gas/m68k-coff/gas.exp: Delete.
	* testsuite/gas/m68k-coff/p2389.s: Delete.
	* testsuite/gas/m68k-coff/p2389a.s: Delete.
	* testsuite/gas/m68k-coff/p2430.s: Delete.
	* testsuite/gas/m68k-coff/p2430a.s: Delete.
	* testsuite/gas/m68k-coff/t1.s: Delete.
	* testsuite/gas/m68k/p3041.d: Delete.
	* testsuite/gas/m68k/p3041.s: Delete.
	* testsuite/gas/m68k/p3041data.d: Delete.
	* testsuite/gas/m68k/p3041data.s: Delete.
	* testsuite/gas/m68k/p3041pcrel.d: Delete.
	* testsuite/gas/m68k/p3041pcrel.s: Delete.
	* testsuite/gas/m68k/t2.d: Delete.
	* Makefile.in: Regenerate.
	* config.in: Regenerate.
	* configure: Regenerate.
	* po/POTFILES.in: Regenerate.
ld/
	* Makefile.am: Remove m68k-aout and m68k-coff support.
	* configure.tgt: Likewise.
	* emultempl/m68kelf.em: Likewise.
	* ld.texinfo: Likewise.
	* mri.c: Likewise.
	* emulparams/delta68.sh: Delete.
	* emulparams/hp300bsd.sh: Delete.
	* emulparams/hp3hpux.sh: Delete.
	* emulparams/m68k4knbsd.sh: Delete.
	* emulparams/m68kaout.sh: Delete.
	* emulparams/m68kaux.sh: Delete.
	* emulparams/m68kcoff.sh: Delete.
	* emulparams/m68klinux.sh: Delete.
	* emulparams/m68knbsd.sh: Delete.
	* emulparams/m68kpsos.sh: Delete.
	* emulparams/sun3.sh: Delete.
	* emultempl/m68kcoff.em: Delete.
	* scripttempl/delta68.sc: Delete.
	* scripttempl/m68kaux.sc: Delete.
	* scripttempl/m68kcoff.sc: Delete.
	* scripttempl/psos.sc: Delete.
	* testsuite/ld-versados/t1-1.ro: Delete.
	* testsuite/ld-versados/t1-2.ro: Delete.
	* testsuite/ld-versados/t1.ld: Delete.
	* testsuite/ld-versados/t1.ook: Delete.
	* testsuite/ld-versados/t2-1.ro: Delete.
	* testsuite/ld-versados/t2-2.ro: Delete.
	* testsuite/ld-versados/t2-3.ro: Delete.
	* testsuite/ld-versados/t2.ld: Delete.
	* testsuite/ld-versados/t2.ook: Delete.
	* testsuite/ld-versados/versados.exp: Delete.
	* Makefile.in: Regenerate.
	* po/BLD-POTFILES.in: Regenerate.

Alan Modra
Australia Development Lab, IBM

[Freemint-discuss] Samba FAT mount

[Peter S. <p....@sc...>]

I am trying to mount a FAT partition /g/photos with Samba.

When I try to access it from the ubuntu box it fails and I think it is
because of the lack of permissions on the folder. It will access /tmp ok.

So I created a sym link /tmp/MyPhotos pointing to /g/photos but that doesn't
work either.

Has anyone done this ?


Peter

[Freemint-discuss] Struct ucontext_t

[Thorsten O. <ad...@th...>]

While experimenting with some code, i noticed that our struct ucontext in sys/
ucontext_h is similar, but not identical to the one from linux/m68k.

The main differences are that, in the general registers, R_PC/R_PS (i think 
that should be the status register?) are reversed, the sigmask is at a 
different location (maybe because on linux a complete set it is more than just 
a long), and the layout of the floating point register set is different. Would 
it be a problem to reorder them? That could make porting some software much 
easier. As far as i can tell, although that structure is defined, it is 
nowhere used: {get,set,make,swap}context are not implemented, and SA_SIGINFO 
isn't either.

Re: [Freemint-discuss] USB FAT errors

[David G. <dga...@gm...>]

2018-03-27 18:13 GMT+02:00 Peter Slegg <p....@sc...>:
>
> I am using Mint build 976 and I am able to mount my mem sticks again
> but it won't let me delete files and also gives FAT errors about
> illegal successor  ...  to cluster ...
>
> Also, it won't "eject" the mem stick either.
>

This driver needs some work, the fact that only works with debug
messages enable........
It's in my TODO list, when I have the time I'll send you some modules
for you to try (if you can of course).

[Freemint-discuss] USB FAT errors

[Peter S. <p....@sc...>]

I am using Mint build 976 and I am able to mount my mem sticks again
but it won't let me delete files and also gives FAT errors about
illegal successor  ...  to cluster ...

Also, it won't "eject" the mem stick either.


Peter

Re: [Freemint-discuss] Thing - selected objects

[Peter S. <p....@sc...>]

On Tue, 27 Mar 2018 13:33:18 , Peter Slegg <p....@sc...> wrote:
> This is odd in Thing 1.50
>
> I am selecting files by dragging the mouse about half-way down
> a list in a folder but after the 16th file the number of
> selected objects shows zero.
>
> I've never seen this before.
>
>
> Peter
>

I think this is due to an issue with the display of the bytes.
You will notice it shows 112.261.3732

The last portion is 4 digits when it should be 3.

It would be nice if it used the TOS delimiter settings as well.


Peter

[Freemint-discuss] Thing - selected objects

[Peter S. <p....@sc...>]

This is odd in Thing 1.50

I am selecting files by dragging the mouse about half-way down
a list in a folder but after the 16th file the number of
selected objects shows zero.

I've never seen this before.


Peter