freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] ELF

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

Is there a native gcc compiler that produces the (mint) elf binaries ?

Other native tools like gdb ?

I've been playing with freepascal. Could it support the same format ?



⁣Peter​

On 3 Dec 2024, 12:59, at 12:59, "Miro Kropáček" <mir...@gm...> wrote:
>On Tue, 3 Dec 2024 at 13:15, Peter Slegg via Freemint-discuss <
>fre...@li...> wrote:
>
>> With Christmas just around the corner, I thought it time to ask how
>is Elf
>> coming along :-)
>>
>Anything specific you have in mind? I've been using the ELF compiler
>for
>nearly a year, (native and finally working) debugger included.
>
>-- 
>http://mikro.atari.org
>
>
>------------------------------------------------------------------------
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] ELF

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

On Tue, 3 Dec 2024 at 13:15, Peter Slegg via Freemint-discuss <
fre...@li...> wrote:

> With Christmas just around the corner, I thought it time to ask how is Elf
> coming along :-)
>
Anything specific you have in mind? I've been using the ELF compiler for
nearly a year, (native and finally working) debugger included.

-- 
http://mikro.atari.org

[Freemint-discuss] ELF

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

With Christmas just around the corner, I thought it time to ask how is Elf coming along :-)



⁣Peter​

Re: [Freemint-discuss] O_GLOBAL issues

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

On Mon, 2 Dec 2024 at 21:08, Jo Even Skarstein via Freemint-discuss <
fre...@li...> wrote:

> What was the outcome of this? Was O_GLOBAL re-introduced? And if so, has
> anybody tested vconsd?
>
Yes, it was: https://github.com/freemint/freemint/pull/379

vcons has a different problem why it doesn't work:
https://github.com/freemint/freemint/issues/118.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] O_GLOBAL issues

[Jo E. S. <jo...@on...>]

On Sun, 2024-09-15 at 13:24 +0200, Miro Kropáček wrote:
> Hi,
> I guess I'll post it here for better visibility. Basically I'm trying
> to solve a bag if issues:

What was the outcome of this? Was O_GLOBAL re-introduced? And if so,
has anybody tested vconsd?

Jo Even

Re: [Freemint-discuss] Food for thought: Linux Patches Allow Kernel Tracing To Work Past Reboots/Crashes

[Eero T. <oa...@he...>]

Hi,

On 12.3.2024 10.44, Thorsten Otto wrote:
> On Montag, 11. März 2024 21:15:42 CET Miro Kropáček wrote:
>> Having the insane (for Atari world) amounts of RAM in TT/CT60/V4S/Aranym,
>> this could work well on our systems, too:
>> https://www.phoronix.com/news/Linux-Tracing-Post-Reboots.

Long before that (by ~20 years), Linux kernels have had ability to dump 
similar things to a specific "oops" partition on the disk:
https://github.com/torvalds/linux/blob/master/drivers/mtd/mtdoops.c


> For aranym atleast, that wont work since the memory may already be cleared by
> the host. Also that assumes that we have some backtrace ability in the kernel,
> which isn't the case.

If you have backtrace ability, like Hatari debugger has (with symbols 
loaded and profiling enabled), one can just print the backtrace when 
things crash.  There's no need to reboot to working config and printing 
things from inside the emulation.

But on real HW, saving other things than backtrace (regs etc) to 
reboot-safe buffer might also be useful.


	- Eero

Re: [Freemint-discuss] Accessing Process Control Block (proc struct)

[Jo E. S. <jo...@on...>]

Ok, got it. This struct is protected and can not be accessed directly, you need to use Fread to access it.

Jo Even


On Thu, 10 Oct 2024 19:28:19 +0000, "Jo Even Skarstein" <jo...@on...> wrote:

>> From tos.hyp (Fcntl):
>>
>> > PPROCADDDR (0x5001):
>> >
>> > In the parameter arg a pointer to the address of the PCB (Process Control Block) is returned.
>>
>> The following code works and prints correct values (when compared with XaAES task manager and ps) when MP is disabled:
>>
>> void main(void)
>> {
>>     long f = Fopen("u:\\proc\\.11", 0); /* Same behaviour when opening .-1 too */
>>     struct PCB *p;
>>     printf("%ld\n", Fcntl((int) f, &p, 0x5001));
>>     printf("pid: %d systime: %ld usrtime: %ld\n", p->pid, p->systime, p->usrtime);
>> }
>>
>> However, if MP is enabled the same binary crashes with a bus error. Fcntl returns E_OK and the value of *p after the call looks sensible, but accessing the memory pointed to by *p results in a bus error. Am I doing something stupid here? I would assume so, since ps (the ancient one from MiNTOS/KGMD/SpareMiNT) works and I'm pretty sure it gets this information the same way.
>>
>> I have compiled it with both gcc and PureC with identical results.
>>
>> Jo Even
>>
>>
>> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

[Freemint-discuss] Accessing Process Control Block (proc struct)

[Jo E. S. <jo...@on...>]

>From tos.hyp (Fcntl):

> PPROCADDDR (0x5001):
>
> In the parameter arg a pointer to the address of the PCB (Process Control Block) is returned.

The following code works and prints correct values (when compared with XaAES task manager and ps) when MP is disabled:

void main(void)
{
    long f = Fopen("u:\\proc\\.11", 0); /* Same behaviour when opening .-1 too */
    struct PCB *p;
    printf("%ld\n", Fcntl((int) f, &p, 0x5001));
    printf("pid: %d systime: %ld usrtime: %ld\n", p->pid, p->systime, p->usrtime);
}

However, if MP is enabled the same binary crashes with a bus error. Fcntl returns E_OK and the value of *p after the call looks sensible, but accessing the memory pointed to by *p results in a bus error. Am I doing something stupid here? I would assume so, since ps (the ancient one from MiNTOS/KGMD/SpareMiNT) works and I'm pretty sure it gets this information the same way.

I have compiled it with both gcc and PureC with identical results.

Jo Even

[Freemint-discuss] Accessing Process Control Block (proc struct)

[Jo E. S. <jo...@on...>]

>From tos.hyp (Fcntl):

> PPROCADDDR (0x5001):
> 
> In the parameter arg a pointer to the address of the PCB (Process Control Block) is returned.

The following code works and prints correct values (when compared with XaAES task manager and ps) when MP is disabled:

void main(void)
{
    long f = Fopen("u:\\proc\\.11", 0); /* Same behaviour when opening .-1 too */
    struct PCB *p;
    printf("%ld\n", Fcntl((int) f, &p, 0x5001));
    printf("pid: %d systime: %ld usrtime: %ld\n", p->pid, p->systime, p->usrtime);
}

However, if MP is enabled the same binary crashes with a bus error. Fcntl returns E_OK and the value of *p after the call looks sensible, but accessing the memory pointed to by *p results in a bus error. Am I doing something stupid here? I would assume so, since ps (the ancient one from MiNTOS/KGMD/SpareMiNT) works and I'm pretty sure it gets this information the same way.

I have compiled it with both gcc and PureC with identical results.

Jo Even

[Freemint-discuss] Test

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

Testing https://github.com/freemint/freemint/issues/386

-- 
http://mikro.atari.org

[Freemint-discuss] Removal of HYPView

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

Hi,

perhaps you are aware, freemint repositories include also
https://github.com/freemint/hypview. This used to be a software developed
by Philipp Donzé (https://xn--donz-epa.ch/atari/software/hypview) which was
moved into freemint cvs in 2006.

Around 2018 Thorsten took this source code as base for this hypview (
https://github.com/th-otto/hypview) and completely reworked it (as it
serves as base for https://tho-otto.de/hypview/index.php and other
non-Atari projects, too).

Since his port has many more features and bugfixes, I'm wondering whether
there is a reason to keep the original under freemint wings. There are
issues (https://github.com/freemint/hypview/issues) not present in
Thorsten's build and there's nobody to fix them.

So I'm considering archiving this repository and removing hypview from
snapshot builds, to encourage people using other alternatives.

Any objections?

-- 
http://mikro.atari.org

Re: [Freemint-discuss] O_GLOBAL issues

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

On Mon, 16 Sept 2024 at 09:03, Thorsten Otto via Freemint-discuss <
fre...@li...> wrote:

> the fix does still not solve all problems with it
>
Like what? AFAIK O_GLOBAL actually fixes *all* the issues with AES 4.1 I
know of and I have even suspected it will fix one other long standing issue
with another piece of software but I have to verify it tonight.

I don't like (re)introducing hacks into the kernel either but in this case
I would say backward compatibility wins over cleanliness. When / if someone
(;-)) manages to recompile AES 4.1 from sources resulting in an exact
binary match and fixes it there, I'll be the first to remove this code from
the kernel.

If you absolutely have to, instead of using a dedicated handle, i would
> suggest to set a bit in the FILEPTR->flags variable instead.
>
Not a bad idea at all, thanks.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] O_GLOBAL issues

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

On Montag, 16. September 2024 08:46:44 CEST Miro Kropáček wrote:
> So allocating one special file descriptor for /dev/console per process seems
> like a better solution I guess?

I just wonder whether we need such ugly hacks at all. For N.AES, there is 
already a solution by setting gemcon=false. AES 4.1 is another matter, but the 
fix does still not solve all problems with it, and (theoretically), source for 
it are available, so it could as well be fixed there.

If you absolutely have to, instead of using a dedicated handle, i would 
suggest to set a bit in the FILEPTR->flags variable instead.

Re: [Freemint-discuss] O_GLOBAL issues

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

On Mon, 16 Sept 2024 at 08:15, Thorsten Otto via Freemint-discuss <
fre...@li...> wrote:

> First off, the mask 0x8000 will result in a negative value if you assign
> it to a 16bit variable.
>
Is that a problem? Fopen() and friends return the corresponding file handle
in the lower WORD of the positive LONG, or a negative error-message. But
even if it were a problem, I can always change the mask to 0x4000 (16k
opened files per process, still far away from the current 1024 limit).


> And secondly, what if you want to use the file handle in a Fselect() or
> Fpoll() call?
>
Hmm. Thanks for this question, it reminded me of one post I saw when trying
to learn something about it:
https://mikro.naprvyraz.sk/mint/199801/msg00110.html. Back then I didn't
understand the question but now I do, and yes, it seems this was a
limitation of O_GLOBAL.

So allocating one special file descriptor for /dev/console per process
seems like a better solution I guess?

-- 
http://mikro.atari.org

Re: [Freemint-discuss] O_GLOBAL issues

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

On Sonntag, 15. September 2024 21:28:11 CEST Miro Kropáček wrote:
> OR'ing e.g. 0x8000 to the resulting file handle would work perfectly well,
> too.

Hm, i don't think this is a good idea. First off, the mask 0x8000 will result 
in a negative value if you assign it to a 16bit variable. And secondly, what 
if you want to use the file handle in a Fselect() or Fpoll() call?

Re: [Freemint-discuss] O_GLOBAL issues

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

>
> I can see the implementation of O_GLOBAL but I'm not 100% confident of its
> purpose. To me it looks like a way to ensure that whatever file is opened
> (even created in the past), it should be always handled as a file belonging
> to the root process ("MiNT") and not others (AESSYS, NEWDESK, SCREEN etc).
> That seems to have some unique properties like ensuring that no key is lost
> due to task switching (or so, happy to be corrected here). The way it was
> implemented was quite weird, basically any process handle >= 100 was
> considered global, essentially limiting the number of open (non-global)
> file handles to 99.
>
I have spent some time looking into this and now I get it (I think). The
idea behind O_GLOBAL is that one process (e.g. the root one) can
open/create a file (identified by a file handle) and other processes
(NEWDESK, AESYSS, ...) can read/write from/to it. You might think "huh? but
why not just pass them the same file handle upon opening?" and that's the
issue here: in a multitasking OS, file handles are a process property. So
file handle = 6 is a different file for "MiNT", different file for "AESSYS"
etc.

In a nutshell:

   - "MiNT" (the kernel) opens /dev/console for read/write
   - "AESSYS" opens /dev/console for read/write with O_GLOBAL and gets a
   file handle
   - ("AESSYS" somehow distributes returned file handle to everyone
   interested, perhaps as "this is the console device")
   - Everyone can now read and write from/to /dev/console as if they were
   all root processes

As this has been deprecated, I'm wondering: couldn't we just make one flag
> in console.c (or dosfile.c) which would tell "this file handle is
>
global because it belongs to /dev/console" and treat it always as root
> process handle?
>
Now we see that this is not possible: we can't compare file handles and
even process IDs: any process is allowed to access the "root file handle"
and yet any process can have the same file handle (e.g. 6) used for
completely different purposes! So the only way to differentiate between
those two is to add some kind of flag to the returned file handle value.
Original MiNT authors decided to use +100 but OR'ing e.g. 0x8000 to the
resulting file handle would work perfectly well, too.

So this is the reason why Helmut's workaround works only partially: it just
pretends that O_GLOBAL doesn't exist. So sometimes it reads from the
correct file handle (AESSYS is reading from regular /dev/console),
sometimes reading fails (e.g. NEWDESK is instructed to open file handle = 6
for accessing /dev/console and it fails because it doesn't have such a file
handle assigned) and sometimes it reads garbage (because file handle = 6 is
e.g. c:\cops.inf and not /dev/console...).

So what can be done about it?

   1. Reverting back to the original O_GLOBAL code for /dev/console but
   using a much bigger offset (e.g. 0x8000, i.e. max 32k opened files)
   2. Making sure that the file handle assigned to "AESSYS" is never used
   in another process, i.e. making the comparison in the way I'm proposing
   above
   3. ???

Having in mind that removal of O_GLOBAL led  to lifting the max file
handles limit from 32 to 1024, I don't have any bad feelings about doing
the first proposal with 0x8000. It's tested and easy to understand but
maybe the second one is a bit cleaner. I don't know.

Oh and since we need this workaround in any case (to make N.AES, AES 4.1
and maybe others happy), we can apply a similar exception to the other bad
boy in town: slip.xif.

-- 
http://mikro.atari.org

[Freemint-discuss] O_GLOBAL issues

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

Hi,

I guess I'll post it here for better visibility. Basically I'm trying to
solve a bag if issues:

   - https://github.com/freemint/freemint/issues/143 (N.AES not working
   with /dev/console)
   - https://github.com/freemint/freemint/issues/173 (AES 4.1 stuck
   keyboard, mouse freeze and non-working double-click)
   - https://github.com/freemint/freemint/issues/378 (basically #173)

All of those are caused by removal of O_GLOBAL handling in
https://github.com/freemint/freemint/commit/9668d6797eaed45ffd9ee8e32770fb04e453f11a.
Helmut realised the same thing and even provided a fix for it:
https://mikro.naprvyraz.sk/mint/201511/msg00014.html so I have just
implemented it in my PR here: https://github.com/freemint/freemint/pull/379.

However, as it turns out, this fix solves most of the issues but not all of
them. Most notably the double-click issue and to some extent also the stuck
key issue (occasionally AES 4.1 still "overflows" with some stray keyboard
characters).

I can see the implementation of O_GLOBAL but I'm not 100% confident of its
purpose. To me it looks like a way to ensure that whatever file is opened
(even created in the past), it should be always handled as a file belonging
to the root process ("MiNT") and not others (AESSYS, NEWDESK, SCREEN etc).
That seems to have some unique properties like ensuring that no key is lost
due to task switching (or so, happy to be corrected here). The way it was
implemented was quite weird, basically any process handle >= 100 was
considered global, essentially limiting the number of open (non-global)
file handles to 99.

As this has been deprecated, I'm wondering: couldn't we just make one flag
in console.c (or dosfile.c) which would tell "this file handle is global
because it belongs to /dev/console" and treat it always as root process
handle?

Thorsten perhaps implied something similar here:
https://github.com/freemint/freemint/pull/379#issuecomment-2351411469 but I
want to double check. To me it seems like the best of both worlds,
/dev/console is always global and we don't need any kludges limiting the
number of open file descriptors.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] Strange problem with program when run twice

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

On Wed, 28 Aug 2024 at 13:30, Thorsten Otto via Freemint-discuss <
fre...@li...> wrote:

> Could there be something wrong in mintlib? Would be rather strange that
> this bug has not occured anywhere else.
>
There always could be something wrong in our Atari world. ;)


> The program needs NVDI to be installed (its purpose is to print out most
> values of the NVDI structure). I've attached it below (pnvdi.tos is the
> Pure-C version, pnvdi is the version compiled by gcc).
>
I guess the first step should be removal of the NVDI dependency (e.g. you
can let it print an uninitialised struct or set it to some custom values),
and then basically shave it to the last printf.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] Strange problem with program when run twice

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

Argl, forget it.

I forgot that i also tried to call some functions in the kernel, but those use 
Pure-C calling convention and cannot be easily called from gcc. But still 
strange that it worked when run for the first time.

[Freemint-discuss] Strange problem with program when run twice

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

Hi,
I have a strange problem here with a program that does some printf to the 
screen and at the same time to a file. It works fine when run for the first 
time. However, when running it again, it
- pauses after some lines of output for a few seconds, then continues
- it then prints a few more lines, and hangs (or pauses for more than 10 min, 
did not wait longer before killing it)

I first thought it might be a problem with toswin2, so i modified the first 
version to write to an output file only, but this had the same effect, even 
when not doing any screen output at all.

Then i thought it might be a problem of aranym, but the same program compiled 
by Pure-C does not have this issue.

Could there be something wrong in mintlib? Would be rather strange that this 
bug has not occured anywhere else.

The program needs NVDI to be installed (its purpose is to print out most 
values of the NVDI structure). I've attached it below (pnvdi.tos is the Pure-C 
version, pnvdi is the version compiled by gcc).

Re: [Freemint-discuss] [freemint/freemint] XaAES window border sizes in medium/low res (Issue #360)

[WongCK <won...@ya...>]

 As a quick fix, just use characters for the classical ST resolutions for now.

    On Tuesday, 20 August 2024 at 07:25:18 pm SGT, skaftetryne <not...@gi...> wrote:  
 
 


Almost all of the widget sets are made for colour/high resolution modes and would not look good in med-res anyway. Maybe a dedicated widget set for med-res would be the easiest solution?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <freemint/freemint/issues/360/229...@gi...>
  

Re: [Freemint-discuss] Qed parameter lost one last letter

[OL <o....@lu...>]

Ok compil cflib and gemlib (need new one for cflib), now Qed work as 
expected

Thanks for help

Olivier
> Ok try compil cflib and see
>
>> And yet another problem could be that I was messing with CF-Lib a 
>> while ago which resulted in a regression in Qed which I just fixed a 
>> couple of days ago: 
>> https://github.com/freemint/qed/commit/502a8b0c2f3e65728e10fdfee8231f5c24a85eb9.
>>
>> While I can't imagine how this particular fix could influence ... 
>> oooooh wait. Do you have the latest CF-Lib installed? Because if you 
>> don't then yes, this can lead to exactly that kind of issue as you 
>> described.
>>
>> On Tue, 20 Aug 2024 at 07:00, Thorsten Otto <ad...@th...> wrote:
>>
>>     On Dienstag, 20. August 2024 00:15:08 CEST OL wrote:
>>
>>     > Any idea why? Issue with my old GCC 4 configuration?
>>
>>
>>     Maybe. Argument parsing is done in mintlib. Another problem could
>>     be how is it started. Does the shell/desktop use ARGV to pass
>>     parameters? Your problem sounds as if someone incorrectly
>>     terminates the commandline in the BASEPAGE.
>>
>>
>>
>>     _______________________________________________
>>     Freemint-discuss mailing list
>>     Fre...@li...
>>     https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>>
>>
>>
>> -- 
>> http://mikro.atari.org
>>
>>
>> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>
>
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] Qed parameter lost one last letter

[OL <o....@lu...>]

Ok try compil cflib and see

> And yet another problem could be that I was messing with CF-Lib a 
> while ago which resulted in a regression in Qed which I just fixed a 
> couple of days ago: 
> https://github.com/freemint/qed/commit/502a8b0c2f3e65728e10fdfee8231f5c24a85eb9.
>
> While I can't imagine how this particular fix could influence ... 
> oooooh wait. Do you have the latest CF-Lib installed? Because if you 
> don't then yes, this can lead to exactly that kind of issue as you 
> described.
>
> On Tue, 20 Aug 2024 at 07:00, Thorsten Otto <ad...@th...> wrote:
>
>     On Dienstag, 20. August 2024 00:15:08 CEST OL wrote:
>
>     > Any idea why? Issue with my old GCC 4 configuration?
>
>
>     Maybe. Argument parsing is done in mintlib. Another problem could
>     be how is it started. Does the shell/desktop use ARGV to pass
>     parameters? Your problem sounds as if someone incorrectly
>     terminates the commandline in the BASEPAGE.
>
>
>
>     _______________________________________________
>     Freemint-discuss mailing list
>     Fre...@li...
>     https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>
>
>
> -- 
> http://mikro.atari.org
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] Qed parameter lost one last letter

[OL <o....@lu...>]

I just drag  a file from desktop on Qed icon to start Qed.
>
> On Dienstag, 20. August 2024 00:15:08 CEST OL wrote:
>
> > Any idea why? Issue with my old GCC 4 configuration?
>
>
> Maybe. Argument parsing is done in mintlib. Another problem could be 
> how is it started. Does the shell/desktop use ARGV to pass parameters? 
> Your problem sounds as if someone incorrectly terminates the 
> commandline in the BASEPAGE.
>
>
>
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] Github workflow dispatch events

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

On Samstag, 17. August 2024 19:41:04 CEST Miro Kropáček wrote:
> I have just fixed a stupid bug in QED and I can't propagate it back to the
> snapshots.

Should be fixed now. Currently building anyway because of the push, but you 
can test afterwards.