freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] Bintray integration / git force-push needed

[Miro K. <mir...@gm...>]

Hi guys,

just resending this email as had been sent just in the middle of the
SourceForge crisis so it's possible it didn't reach everyone. I have last
few days of my time available to do this so it would be nice if we reach
some agreement here, especially from Alan. IMO it's worth the small
annoyance (as we gain a smaller repository, non-polluted history, ...).

On 24 February 2018 at 09:45, Miro Kropáček <mir...@gm...> wrote:

> Hi guys,
>
> I had a few free afternoons so I finally looked into
> https://github.com/freemint/freemint/issues/79. Encouraged by Vincent's
> and Thorsten's deployment experiments I've decided to try something new and
> exciting too. :)
>
> You can see the result here: https://github.com/mikrosk/freemint, namely:
>
>    - (supposedly) faster boot times; I didn't have to use 'sudo' (thanks
>    to Vincent's launchpad repository + the apt plugin) therefore Travis uses a
>    Docker image instead of a full VM
>    - 99% travis-clean git history; only one commit is present (adding
>    .travis.yml)
>    - 99% guarantee that the history will stay travis-clean in the future;
>    if you look into .travis.yml you'll see it's basically just a stub,
>    everything is downloaded and applied automatically
>    - no more dilemmas with improving build scripts -- in fact, you can
>    deploy new stuff on the same source base again and again, just using Travis
>    "restart build" functionality (so the new build script would be downloaded
>    but the version etc would be kept)
>    - no more abusing of https://github.com/freemint/travis-pr and
>    https://github.com/freemint/freemint.github.io
>    <https://github.com/freemint/freemint.github.io> for build outputs,
>    everything goes to bintray: https://bintray.com/freemint/freemint
>    - fancy download icons ;), nice download statistics, ...
>
> The final burst of motivation was adding Bintray support to Travis, so
> instead of this dark magic
> <https://github.com/aranym/aranym/blob/master/.travis/deploy.sh> (hats
> off, Thorsten!) I could do just this
> <https://github.com/mikrosk/travis-scripts/blob/freemint-master/travis-freemint-master/bintray.desc>
> .
>
> It comes, however, with a price:
>
>    - git history has to be totally rewritten, so if you have a
>    branch/fork of your own, you have to do a hard reset + rebase/cherry-pick
>    - we lost the nice links in pull requests, the PR author has to
>    manually post the link back to bintray if someone request the build...
>
> It's still not 100% finished (for instance pull requests) but you get the
> idea. I have also taken the liberty to clean up a few things in the git
> tree like doing a real git merge of the branch "usbtos" (way harder than I
> had thought...) or removing/squashing few similar/non-source commits
> (.cvsignore -> .gitignore for instance).
>
> I'm writing this in advance to give you time to stop me -- otherwise I'll
> do the git force-push sometime on Sunday.
>
> --
> MiKRO / Mystic Bytes
> http://mikro.atari.org
>



-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

[Freemint-discuss] Bug report and patch

[Roger B. <an...@xp...>]

The attached patch fixes a bug in the TOSONLY code in usb_storage.c.  It does 
not affect FreeMiNT, but it does affect the STORAGE.PRG that is used in support 
of USB sticks on plain TOS (and EmuTOS), and the code is in the FreeMiNT 
sources, so I am submitting the patch here.

Problem description:
During STORAGE.PRG startup, if the current max_sect_siz in the AHDI structure 
is not the same as the maximum logical sector size obtained from XHDI, the 
program installs a new AHDI structure and a new set of cache buffers.  It then 
copies the data from the old buffers to the new ones.  However, it only copies 
the first 512 bytes of each buffer; the rest of the buffer was zeroed after 
being malloc'ed and remains that way.

As a result, if max_sect_siz is not the same as the XHDI size, and max_sect_siz 
is greater than 512, the in-memory copy of sectors will be corrupt after 
STORAGE.PRG has run.  If the cached sectors are from directories, then files or 
folders will temporarily disappear; if those sectors are subsequently written 
to, the bad data will be flushed to disk, causing filesystem corruption.

Fix:
The fix merely sets the copy length correctly.

Roger Burrows

Re: [Freemint-discuss] Chroot Troubles

[Adam K. <ada...@gm...>]

2018-02-20 17:20 GMT+01:00 Thorsten Otto <ad...@th...>:

> On Montag, 19. Februar 2018 18:57:52 CET Mark Duckworth wrote:
> > IIRC chroot is done in MiNTlib, without kernel involvement. So, it
>
> > > depends on how each binary was compiled.
>
> That's not true. The only thing mintlib does is to implement the chroot()
> posix function, by directing it to the Dchroot() MiNT call.
>
>
It used to be true a long time ago it seems. It also seems that Dchroot()
seems to be very incomplete.

-- 
Semper Fidelis

Adam Klobukowski
ada...@gm...

Re: [Freemint-discuss] Mailing list problems

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

That message if you don't know is from spamassassin.  It'd be good to
know if sourceforge's mail server added it or your sending mail server. 
Regardless, 4.1 is pretty spammy ;)

Thanks,

Mark



On 02/27/2018 04:25 PM, Miro Kropáček wrote:
> On the other hand I don't see your (or mine for that matter) email in
> the archives, hm.
>
> On 28 February 2018 at 08:22, Miro Kropáček <mir...@gm...
> <mailto:mir...@gm...>> wrote:
>
>     Yup, arrived sound & safe. :)
>
>     On 28 February 2018 at 03:29, Thorsten Otto <ad...@th...
>     <mailto:ad...@th...>> wrote:
>
>         Just a test, because some of my recent mails were bounced with
>
>         <fre...@li...
>         <mailto:fre...@li...>>: host
>         mx.sourceforge.net <http://mx.sourceforge.net>[216.105.38.6]
>             said: 550 This message scored 4.1 points. Congratulations!
>         (in reply to
>         end
>             of DATA command)
>
>         Sorry for the noise
>
>
>
>         ------------------------------------------------------------------------------
>         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...
>         <mailto:Fre...@li...>
>         https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>         <https://lists.sourceforge.net/lists/listinfo/freemint-discuss>
>
>
>
>
>     -- 
>     MiKRO / Mystic Bytes
>     http://mikro.atari.org
>
>

Re: [Freemint-discuss] Chroot Troubles

[Adam K. <ada...@gm...>]

IIRC chroot is done in MiNTlib, without kernel involvement. So, it depends
on how each binary was compiled.

AdamK

2018-02-17 4:38 GMT+01:00 Mark Duckworth <mdu...@at...>:

> Hello all,
>
> Once upon a time I was told that chroot in mint works fine.  I decided
> to try it and on the surface it looks good but when I dig deeper there
> is issues.  Here it is demonstrated.  Current kernel, coreutils chroot
> binary.
>
> Create a bootstrap under /root/bootstrap  Not much under there, just
> coreutils, rpm and a few other things.
>
> root@bf3:/root>chroot /root/bootstrap /bin/bash
> bash-2.05a# pwd
> /e/root/bootstrap
> bash-2.05a# ls
> bin  etc  sbin  usr  var
> bash-2.05a#
>
> Ok so bash doesn't find anything which means bash is respecting the
> chroot.  We did change directories but pwd can see it is not in a new root.
>
> bash-2.05a# ls
> bin  etc  sbin  usr  var
> bash-2.05a# pwd
> /
> bash-2.05a#
>
> Ok but we can go to / and the chroot is adhered to.  Maybe we can
> proceed.  What is under /var
>
> bash-2.05a# ls
> adm  catman  log
> bash-2.05a#
>
> Ok so proceed.
>
> bash-2.05a# rpm -qa
> automake-1.11.1-1
> info-4.0-2
> cpio-2.4.2-3
> procps-ng-3.3.2-1
> bzip2-1.0.2-1
>
> ....
>
> and so on.  The rpm database is the one from outside the chroot.  Any
> ideas?
>
> Thanks,
>
> Mark
>
>
>
>
> ------------------------------------------------------------
> ------------------
> 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
>



-- 
Semper Fidelis

Adam Klobukowski
ada...@gm...

Re: [Freemint-discuss] Mailing list problems

[Miro K. <mir...@gm...>]

On the other hand I don't see your (or mine for that matter) email in the
archives, hm.

On 28 February 2018 at 08:22, Miro Kropáček <mir...@gm...> wrote:

> Yup, arrived sound & safe. :)
>
> On 28 February 2018 at 03:29, Thorsten Otto <ad...@th...> wrote:
>
>> Just a test, because some of my recent mails were bounced with
>>
>> <fre...@li...>: host
>> mx.sourceforge.net[216.105.38.6]
>>     said: 550 This message scored 4.1 points. Congratulations! (in reply
>> to
>> end
>>     of DATA command)
>>
>> Sorry for the noise
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> 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
>>
>
>
>
> --
> MiKRO / Mystic Bytes
> http://mikro.atari.org
>



-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

Re: [Freemint-discuss] Mailing list problems

[Miro K. <mir...@gm...>]

Yup, arrived sound & safe. :)

On 28 February 2018 at 03:29, Thorsten Otto <ad...@th...> wrote:

> Just a test, because some of my recent mails were bounced with
>
> <fre...@li...>: host
> mx.sourceforge.net[216.105.38.6]
>     said: 550 This message scored 4.1 points. Congratulations! (in reply to
> end
>     of DATA command)
>
> Sorry for the noise
>
>
>
> ------------------------------------------------------------
> ------------------
> 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
>



-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

[Freemint-discuss] Mailing list problems

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

Just a test, because some of my recent mails were bounced with

<fre...@li...>: host 
mx.sourceforge.net[216.105.38.6]
    said: 550 This message scored 4.1 points. Congratulations! (in reply to 
end
    of DATA command)

Sorry for the noise

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

[David G. <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

Re: [Freemint-discuss] Bintray integration / git force-push needed

[Miro K. <mir...@gm...>]

On 24 February 2018 at 09:45, Miro Kropáček <mir...@gm...> wrote:

> It's still not 100% finished (for instance pull requests)
>
Btw Thorsten, how did you solve this? I see Aranym's deploy.sh contains a
check for BINTRAY_API_KEY however I still don't get it -- I, as a foreign
contributor, create a bintray account, setup the ENV variable in my travis
build and ... how the pull request output makes it into aranym's
pullrequests folder? Is there a hidden implication that I have to be a
member of 'aranym' bintray organisation?

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

Re: [Freemint-discuss] Bintray integration / git force-push needed

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

2018-02-24 1:42 GMT+01:00 Miro Kropáček <mir...@gm...>:
> On 24 February 2018 at 11:27, Thorsten Otto <ad...@th...> wrote:
>> All these forks will be affected by this, too, and of course every repo
>> that someone has cloned locally. That will be at least as much work that you
>> did, for everybody who is affected, maybe even worse
>
> Actually, it's not that bad. One just has to fetch from the upstream origin,
> reset his local master (or any other branch) to upstream and force push to
> his own github repository. That will make the fork in sync again. The only
> issue is dev branches, i.e. one has to manually go branch by branch and
> rebase/cherry-pick on the top of the new commit ID.
>
> I'm of course prepared to offer advice/assistance -- trust me, I'm no git
> expert at all and I could manage quite easily. One just has to be careful to
> push to the right remote. ;-)
>

I don't have too much knowledge about this matter, so I can't give you
any valuable opinion.
The only thing I can tell you is that one of this forks is mine but I
didn't do anything with it, so it's not an issue for me the forced
history change.

Re: [Freemint-discuss] Bintray integration / git force-push needed

[Miro K. <mir...@gm...>]

On 24 February 2018 at 11:27, Thorsten Otto <ad...@th...> wrote:


> >git history has to be totally rewritten, so if you have a branch/fork of
> your
> >own, you have to do a hard reset + rebase/cherry-pick
>
> I wouldn't do that if it can be avoided.

I wouldn't if it could be avoid as well. :) The biggest pain is that now
the repo contains EmuTOS, TeraDesk, fVDI etc. So it prolongs git clone for
everybody and serves no purpose.

All these forks will be affected by this, too, and of course every repo
> that someone has cloned locally. That will be at least as much work that
> you did, for everybody who is affected, maybe even worse
>
Actually, it's not that bad. One just has to fetch from the upstream
origin, reset his local master (or any other branch) to upstream and force
push to his own github repository. That will make the fork in sync again.
The only issue is dev branches, i.e. one has to manually go branch by
branch and rebase/cherry-pick on the top of the new commit ID.

I'm of course prepared to offer advice/assistance -- trust me, I'm no git
expert at all and I could manage quite easily. One just has to be careful
to push to the right remote. ;-)


> >otherwise I'll do the git force-push sometime on Sunday.
>
> I would wait a few days more. SF still seems to have problems with their
> mailing lists, maybe the complaints just don't make it to the list.
>
Fair enough, there's no rush.

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

Re: [Freemint-discuss] Bintray integration / git force-push needed

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

On Freitag, 23. Februar 2018 23:45:02 CET Miro Kropáček wrote:
> no more abusing of https://github.com/freemint/travis-pr and
> https://github.com/freemint/freemint.github.io

That was absolutely necessary, especially for freemint.github.io where the 
snapshots are pushed to, and which has already grown to more than 600MB when 
you clone it. The *.io areas are limited to 1GB IIRC.

> The final burst of motivation was adding Bintray support to Travis

Oh. I didn't notice yet.

>The final burst of motivation was adding Bintray support to Travis, so  
>instead of this dark magic (hats off, Thorsten!) I could do just this.

It was still a good experience ;) And it's still a bit more flexible, since  
the same script can be used for snapshots and releases. Also, it looks that 
this kind of REST API that bintray uses is quite common, so it can easily be 
adapted for other providers or tasks.

>git history has to be totally rewritten, so if you have a branch/fork of your 
>own, you have to do a hard reset + rebase/cherry-pick

I wouldn't do that if it can be avoided. Might be a bit annoying to have the 
Travis commits in the log, but better than resetting it to a completely new 
repo. If you look at the link at the top, you will see that is has already 
been forked 9 times. All these forks will be affected by this, too, and of 
course every repo that someone has cloned locally. That will be at least as 
much work that you did, for everybody who is affected, maybe even worse (eg. i 
will have to clean up at least 2 repos, the cloned originally freemint repo, 
and the clone of my fork). And not everybody might know what he is doing there 
(remember my first attempts with the PRs  *cough*). Also, to be honest, i 
rather spend my time  with developing than with managing the repos.

>otherwise I'll do the git force-push sometime on Sunday.

I would wait a few days more. SF still seems to have problems with their 
mailing lists, maybe the complaints just don't make it to the list.

[Freemint-discuss] Bintray integration / git force-push needed

[Miro K. <mir...@gm...>]

Hi guys,

I had a few free afternoons so I finally looked into
https://github.com/freemint/freemint/issues/79. Encouraged by Vincent's and
Thorsten's deployment experiments I've decided to try something new and
exciting too. :)

You can see the result here: https://github.com/mikrosk/freemint, namely:

   - (supposedly) faster boot times; I didn't have to use 'sudo' (thanks to
   Vincent's launchpad repository + the apt plugin) therefore Travis uses a
   Docker image instead of a full VM
   - 99% travis-clean git history; only one commit is present (adding
   .travis.yml)
   - 99% guarantee that the history will stay travis-clean in the future;
   if you look into .travis.yml you'll see it's basically just a stub,
   everything is downloaded and applied automatically
   - no more dilemmas with improving build scripts -- in fact, you can
   deploy new stuff on the same source base again and again, just using Travis
   "restart build" functionality (so the new build script would be downloaded
   but the version etc would be kept)
   - no more abusing of https://github.com/freemint/travis-pr and
   https://github.com/freemint/freemint.github.io
   <https://github.com/freemint/freemint.github.io> for build outputs,
   everything goes to bintray: https://bintray.com/freemint/freemint
   - fancy download icons ;), nice download statistics, ...

The final burst of motivation was adding Bintray support to Travis, so
instead of this dark magic
<https://github.com/aranym/aranym/blob/master/.travis/deploy.sh> (hats off,
Thorsten!) I could do just this
<https://github.com/mikrosk/travis-scripts/blob/freemint-master/travis-freemint-master/bintray.desc>
.

It comes, however, with a price:

   - git history has to be totally rewritten, so if you have a branch/fork
   of your own, you have to do a hard reset + rebase/cherry-pick
   - we lost the nice links in pull requests, the PR author has to manually
   post the link back to bintray if someone request the build...

It's still not 100% finished (for instance pull requests) but you get the
idea. I have also taken the liberty to clean up a few things in the git
tree like doing a real git merge of the branch "usbtos" (way harder than I
had thought...) or removing/squashing few similar/non-source commits
(.cvsignore -> .gitignore for instance).

I'm writing this in advance to give you time to stop me -- otherwise I'll
do the git force-push sometime on Sunday.

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

Re: [Freemint-discuss] Chroot Troubles

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

On Dienstag, 20. Februar 2018 19:29:06 CET Adam Klobukowski wrote:
> It used to be true a long time ago it seems

I don't think so. If you look at git log -p unix/chroot.c, the last change 
there is from 2001. And even that patch didn't change much, there is nothing 
that indicates that mintlib manages the root directory itself. Wouldn't make 
much sense anyway, since every program would still be able to get out of the 
jail by using the GEMDOS calls directly.

>It also seems that Dchroot() seems to be very incomplete.

Thats more likely the problem. For example, when chrooted, pathnames with 
drive letters shouldn't be allowed (except maybe u:).


PS.: pls send discussions to the list, otherwise ppl. wonder what we are 
talking about ;)

Re: [Freemint-discuss] Chroot Troubles

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

On Montag, 19. Februar 2018 18:57:52 CET Mark Duckworth wrote:
> IIRC chroot is done in MiNTlib, without kernel involvement. So, it

> > depends on how each binary was compiled.

That's not true. The only thing mintlib does is to implement the chroot() 
posix function, by directing it to the Dchroot() MiNT call.

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

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

On 20/02/2018 at 00:46, Thorsten Otto wrote:
> Yes i think so. Those lowercase versions have always been there for all m68k
> platforms, with and without underscores (if you don't use -ansi), while the
> uppercase versions have only been patched in by the mint patch, for
> compatibility with some very old ports. Also, there is no uppercase equivalent
> for -m68030 or better, they all define only __M68020__. So, although that is
> fixed now, the code should check for __mc68020__ instead.

I agree with you. From the top of my head, I went to the same conclusion 
long ago. Of course, we should use new official GCC defines.

-- 
Vincent Rivière

Re: [Freemint-discuss] GCC 7.3 / binutils 2.30

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

Thanks for continuing this!

On 02/19/2018 09:23 PM, Thorsten Otto wrote:
>
> Hi
>
>  
>
> i have just uploaded updated packages, available as separate packages
> or all-in-one. There is now also a cross-compiler available for MinGW
> (plain windows executables). The packages are available here
> <http://tho-otto.de/crossmint.php> .
>
>  
>
> There was also a small bug fixed in GCC which did not set the
> compatibility macro __M68020__ any more (as discussed on github and
> also here). Other than that, there were no new mint specific patches
> (a lot of the new commits are only for using MinGW as a host for a
> cross-compiler, what a mess).
>
>
>

[Freemint-discuss] GCC 7.3 / binutils 2.30

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

Hi

i have just uploaded updated packages, available as separate packages or all-
in-one. There is now also a cross-compiler available for MinGW (plain windows 
executables). The packages are available here .

There was also a small bug fixed in GCC which did not set the compatibility 
macro __M68020__ any more (as discussed on github and also here). Other than 
that, there were no new mint specific patches (a lot of the new commits are 
only for using MinGW as a host for a cross-compiler, what a mess).

Re: [Freemint-discuss] TOSWIN colours

[Miro K. <mir...@gm...>]

Come on, I've been using it for ages, works wonderfully. As you say, it's
just matter of making an alias for ls, grep and find. :)

On 20 February 2018 at 11:32, Thorsten Otto <ad...@th...> wrote:

> In theory, yes, because that is not done by the shell, but by the tools
> like
> ls. However the color capabilities of a vt52 (or even a vt100) that are
> supported by toswin2 are rather limited.
>
>
>
>
> ------------------------------------------------------------
> ------------------
> 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
>



-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

Re: [Freemint-discuss] TOSWIN colours

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

In theory, yes, because that is not done by the shell, but by the tools like 
ls. However the color capabilities of a vt52 (or even a vt100) that are 
supported by toswin2 are rather limited.

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

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

Edit: in the mint kernel, things might be different. Some macros like M68000 
are explicitly defined in cdefs.h, which is generated by the Makefile. But you 
are right, there all still a few places that check for __M68020__ instead. 
maybe that is because of this strangeness:

ifeq ($(kernel),020)
MINT = mint020.prg
CPU  = 020
KERNELDEFS = -DM68000
kernel_nocflags = -DWITH_MMU_SUPPORT
endif

Note that only M68000 is defined there, not M68020.

If you are going to use the compiler generated symbols instead, keep in mind 
that switches like -m68020-60 will define *all* macros from __mc68020 to 
__mc68060, but the compiler will generate code that still runs on 68020.

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

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

On Montag, 19. Februar 2018 09:45:07 CET David Gálvez wrote:
> but it's still no clear to me what is state of these macros in
> gcc 7. Can use them safely?

Yes i think so. Those lowercase versions have always been there for all m68k 
platforms, with and without underscores (if you don't use -ansi), while the 
uppercase versions have only been patched in by the mint patch, for 
compatibility with some very old ports. Also, there is no uppercase equivalent 
for -m68030 or better, they all define only __M68020__. So, although that is 
fixed now, the code should check for __mc68020__ instead.

Re: [Freemint-discuss] Chroot Troubles

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

Thank you sir, that explains everything.

Thanks,
Mark


On 02/19/2018 06:08 AM, Adam Klobukowski wrote:
> IIRC chroot is done in MiNTlib, without kernel involvement. So, it
> depends on how each binary was compiled.
> 
> AdamK
> 
> 
> 
> -- 
> Semper Fidelis
> 
> Adam Klobukowski
> ada...@gm... <mailto:ada...@gm...>

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

[David G. <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?


----------------------------------------------
th-otto commented 9 hours ago •

Do you know if gcc 7 still creates a M68020 macro for them?

what i usually do to check things like that:

echo "" | m68k-atari-mint-gcc -dM -E - | grep -i m680

(adding switches you want to test)

And mirko is right, gcc 7 does not define m68020 (or the uppercase
version) anymore. Thats bad. Even worse, when using m68020-60, m68020
is defined, but not m68000 (the latter should be defined for any m68k
target).

I don't think its the fault of our port, but i will check that.

edit: ok the test with -dM did not work in this case. The reason is
that this only prints the symbols that are generated by the code, but
M68020 etc. are generated by entries in the spec file (you can see it
by using gcc -dumpspecs). So for the compiled code, these symbols are
still visible.

Owner

mikrosk commented 9 hours ago

M68020 etc. are generated by entries in the spec file (you can see it
by using gcc -dumpspecs). So for the compiled code, these symbols are
still visible.

@th-otto are you sure? I've tested #ifdef __M68020__ directly with a C
source file and wasn't defined for anything but -m68020-40 and
-m68020-60. Or did I misunderstand your comment?

Contributor

th-otto commented 9 hours ago

@Mikro no i'm not sure :) that said, i haven't tested to compile a
program. But it is defined in the spec file, and it has been like also
for gcc 4.6.4, so i assumed they behave the same in that manner.

Contributor

th-otto commented 6 hours ago

Hm there is definitely something wrong with the definitions coming
from the spec file, but i coudn't figure out yet what. It has been the
same definition for ages (CPP_SPEC in config/m68k/mint.h). However
there is a simple solution: just test for mc68020 instead. The
uppercase versions are old relicts anyway.

Edit: i just saw that the definition of asm_cpu_spec is different
between 4.6.4 and 7.2. That definition wasn't touched by our mint
patch, so i guess it has changed for m68k in general, and seems to
cause different behaviour now.



2018-02-18 23:58 GMT+01:00 Miro Kropáček <mir...@gm...>:
> Hi David,
>
> if the interpretation you've mentioned in
> https://github.com/freemint/freemint/issues/70 holds for all drivers (i.e.
> that the delay is supposed to wait at least X microseconds) there shouldn't
> be any regressions IMHO -- the new formula must definitely take longer than
> the previous stub.
>
> As for your question about "__M68020__": gcc 7.2 emits them only for
> -m68020-40 and -m68020-60 (no, not even -m68020!). It definitely seems like
> some kind of deprecated macro kept only for the minimal backward
> compatibility.
>