What I expect on Update3

[Mrodfr]

Hello,

My first post on this forum

First thanks to have opened more AOS4 and Hyperion to the customers (SSolie at the head, created the Blog for news and this official forum , the SSolie statement about update3 (and a maybe theorically another update if necessary),…..)

With theses new actions created around AOS and Hyperion, I have now more hope about the future of my preferred computer system. (Hyperion now stop to be a kind of secret society

The next update of the AOS approached and each Amiga-OS users have their own hope about the next update. I would like to explain here what I would like to see included on the update because I need to have this compoments updated for my daily use of the AOS4 computer.

- Using Amigygnix on PIP mode (updated GFX driver) and maybe Amicygnix could be used with more speed with the new RTG.library.

- A better debug system. I’m tired to have half of the time a computer freezed when a crash came. I really wish to see all the time a DSI with enough informations about the problem. (mainly elf.kmod updated and surely others parts).

- USB2 fixed and enhanced and CROSSDOSfilesystem fixed and reliable. I’m using Debian on the SAM mostly for copying safely datas on my FAT95 USB medias and I really would like to have a good and reliable support with USB2 and FAT formatted medias.

- Warp3D Fixed (thanks to Karlos and Hans). It’s verry important for me to see Warp3D fixed and debugged. I’m not saying that Warp3D should be improved but fixing the warp3D problems could give 10-20% betters frame for 3D applications. This for waiting after Gallium3D.

This are mainly the main points I expect and wait after improvements on Update3 (I have surely forgotten some .

If some main developpers could comments the points I have explained by interesting explanations, I will be verry pleased

bye

[tonyw]

@Mrodfr:

I can't answer all of your questions - no one can, since the exact contents of Update3 are not frozen in concrete. It's a snapshot of the current development status.

We have a version of Update 3 that is being tested at the moment. There have been more than six versions to test already. It's different from last week's version and there might be a new version next week. It depends on what happens as it is tested. All the betatesters are checking it out on all the different hardware platforms.

If The Boss decides that we don't need to delay any longer and this version is good enough, then he will release this version.

If we discover a new (major) bug in a new component and it looks as though it might take weeks to fix and test, then we might take out the new component and use the previous version. On the other hand, if one of the developers releases an update that makes a big improvement to a component, then the update might be delayed until we test the new component.

Please be patient - we'll all know soon just what is going to be released and to which version. Then, when it's up on the website and you guys can get hold of it, we can go back to testing the system components for Update 4 or Release 4.2 (or whatever it's going to be).

[Hans-Joerg Frieden]

Using Amigygnix on PIP mode (updated GFX driver) and maybe Amicygnix could be used with more speed with the new RTG.library.

I am not quite sure what you mean, AmiCygnix doesn't have anything to do with AmigaOS 4.x, it's a third party application/package (A good one, but hardly anything we can address with an update).

A better debug system. I’m tired to have half of the time a computer freezed when a crash came. I really wish to see all the time a DSI with enough informations about the problem. (mainly elf.kmod updated and surely others parts).

I wonder why you think that elf.library has anything to do with debugging.
The reason why a lot of crashes end up in a deadlock is known to us and is something we'll be looking at. Furthermore, we're working on a new version of GDB which we hope to deploy with the Update 3 SDK, but that's just an intention right now, and might not happen.

fixing the warp3D problems could give 10-20% betters frame for 3D applications

Hm, please explain how you get to that conclusion.

Anyway, further work on Warp3D is unlikely, especially for such marginal increases in performance. That time is much better invested into Gallium3D.

[Mrodfr]

Using Amigygnix on PIP mode (updated GFX driver) and maybe Amicygnix could be used with more speed with the new RTG.library.

I am not quite sure what you mean, AmiCygnix doesn't have anything to do with AmigaOS 4.x, it's a third party application/package (A good one, but hardly anything we can address with an update).

Yes but AFAIR, It's not possible to use amicygnix in PIP mode, because caused by a problem on the GFX driver contained on the update2 (At least for the SAMs computers).

A better debug system. I’m tired to have half of the time a computer freezed when a crash came. I really wish to see all the time a DSI with enough informations about the problem. (mainly elf.kmod updated and surely others parts).

I wonder why you think that elf.library has anything to do with debugging.

The reason why a lot of crashes end up in a deadlock is known to us and is something we'll be looking at. Furthermore, we're working on a new version of GDB which we hope to deploy with the Update 3 SDK, but that's just an intention right now, and might not happen.

I'm talking about db101, who Needs at least elf.library 53.13 (currently beta) to work (this is just a part of the better debug system). Also a new GDB version will also help a lot to locate efficiently DSI problems.

The interesting part of your answer is the deadlock problem AOS4 developpers looking at. It's a verry stressfull one for common users because allways must switch ON/OFF the comuter

[kas1e]

@Hans

Furthermore, we're working on a new version of GDB which we hope to deploy with the Update 3 SDK, but that's just an intention right now, and might not happen.

That is awesome news. I am right now writing some small article about debugging for os4coding.net, and while i works on it, i thinking about writing one more topic on there, with asking about new version of GDB, which will be awesome and cool. And so, you say its already in the works and its really good news. Even better than some others.

As far as i remember, currently GDB have some problems (as well as GR just very offten crashes when you trying to attach it to GDB), and one of these problems, its unpossibility to do remotely with it (and its imho because of msr register problem, about which check nextly).

Related to db101 (in case you didnt know, its new gui-debugger from alfkil (who works on QT) ), there is screenshot and binary , and for sure you should notice the sources on adtool page already So, it has 3 bugs on update2, which all related to os4:

-- There are some problems with elf.library.kmod in AmigaOS Update 1 and Update 2, so from this version it is only going to work with a pre-update 1 elf.library or with the latest beta version (53.13). Sorry for this, but there is no workaround

-- There is also a problem with the msr register, which means, that if you by any chance place a breakpoint on top of a branch, things are going to mess up. There is more deep details about from Alfkil:

In the meantime I have run into a catastrophical problem (one more besides the elf.library thing...):

Setting the msr |= MSR_TRACE_ENABLE (0x400) from the exception context doesn't work . This means, that I'm not going be able to do proper handling of loops etc before that is fixed. This is probably the very same problem that keeps GDB from being remotely functional.

Just to explain: Setting this processor flag should make the processor yield an exception after executing exactly one instruction. Of course I can easily install a TRAP instruction on the next coming instruction, but this doesn't take into account, that the processor might do a branch during that very same cycle. Doing a trace would automatically leave the ip at the branched address, but to be able to do that with a patch would be breaking an arm and a leg. Doh!

-- There is a problem with the gnu linker, which means that reading of type definitions doesn't work properly for executables consisting of more than one source file. More info about:

There is a bug in the linker (dl) that leaves out a bunch of debug info from the final executable. What this means is, that if you are compiling multiple files into one executable, you are not going to be able to read the typedefs properly. So when the "Locals" or "Globals" windows just show you "UNKNOWN", this is _not_ my fault, it is a bug in the linker... Doh!

So, problem #1 already solved, but dunno about problem 2 and 3. If you works on new GDB version, i assume MSR register problem will also be fixed, and maybe linker (dl) are fixed as well ..

[ssolie]

I am not quite sure what you mean, AmiCygnix doesn't have anything to do with AmigaOS 4.x, it's a third party application/package (A good one, but hardly anything we can address with an update).

There is some bug in the PIP support but CygnusEd (the author) has not yet managed to contact any of us to record the bug so it remains unsolved. We need a simple test program at a minimum to reproduce the issue.

[ssolie]

I'm talking about db101, who Needs at least elf.library 53.13 (currently beta) to work (this is just a part of the better debug system). Also a new GDB version will also help a lot to locate efficiently DSI problems.

I've worked with Alfkil on a few issues already. How do you think he got the beta elf.library to test with?

[Mrodfr]

I am not quite sure what you mean, AmiCygnix doesn't have anything to do with AmigaOS 4.x, it's a third party application/package (A good one, but hardly anything we can address with an update).

There is some bug in the PIP support but CygnusEd (the author) has not yet managed to contact any of us to record the bug so it remains unsolved. We need a simple test program at a minimum to reproduce the issue.

Some explanation for cygnusEd are on http://www.amigans.net/modules/xforum/v ... &order=ASCthis thread.

If It's just a matter of a link between 2 peoples, I will contact him tomorow and will point to him this thread.

EDIT: email send


NOTE: Hum, the URL button work or I don't arrive to use it ?

[Mrodfr]

I'm talking about db101, who Needs at least elf.library 53.13 (currently beta) to work (this is just a part of the better debug system). Also a new GDB version will also help a lot to locate efficiently DSI problems.

I've worked with Alfkil on a few issues already. How do you think he got the beta elf.library to test with?

As you know , I'm stressed when I debug on AOS4 (for third party programmer sometime) because half of the time, the answer I have from a developper is: sorry I don't found the problem. With AOS3 and MUforce, no problems

You add the elf.library problems reported by kas1e (on his previous post) and alkfill and a little of addr2line little problem (use the exact command line) and a outdated GDB for C programs compiled in debug mode and the result is not satisfacted :-\

An idea:

Adding addr2line and GDB as standard on the AOS and add more buttons on the Grim Reaper window should simplify a lot the manner to create the best output as possible in case of a problem encountered.

Thanks to kas1e for reporting the elf.library problem with more details than me

bye

[Hans-Joerg Frieden]

Adding addr2line and GDB as standard on the AOS and add more buttons on the Grim Reaper window should simplify a lot the manner to create the best output as possible in case of a problem encountered.

gdb and addr2line are developer tools, and completely useless if the binary doesn't contain debug info (which is true for almost any released software), so adding them to anything but the SDK isn't really making much sense