Who's Online |
162 user(s) are online ( 93 user(s) are browsing Forums)
Members: 1
Guests: 161
smf,
more...
|
|
Headlines |
-
mce.lha - game/utility
Apr 23, 2024
-
theme_list.lha - utility/misc
Apr 23, 2024
-
faac.lha - audio/convert
Apr 22, 2024
-
faad2.lha - audio/convert
Apr 22, 2024
-
seq.lha - audio/misc
Apr 22, 2024
-
libfaac.lha - development/library/audio
Apr 22, 2024
-
libfaad.lha - development/library/audio
Apr 22, 2024
-
image2pdf.lha - utility/text/convert
Apr 22, 2024
-
libharfbuzz.lha - development/library/graphics
Apr 20, 2024
-
libpng.lha - development/library/graphics
Apr 20, 2024
|
|
|
|
|
Re: Updater tool: latest releases and updates
|
|
Just popping in 
|
@kas1e
No, AmigaKit has nothing whatsoever to do with AmiSSL - only Hyperion have made a contribution to the development... Way back when AmiSSL was closed-source, some sort of deal was done with Hyperion to make AmiSSL (v3) a integral component of AmigaOS 4.0, hence why the libs are installed in LIBS: and the cmd in C:, for example (they go in AmiSSL: on other systems). It is still a key component of AmigaOS 4.x, of course, and AmiUpdate also uses it to support HTTPS downloads.
I have full control of the releases to GitHub, AmiUpdate and Aminet, hence those are the only official release channels. AmiUpdate gets AmiSSL from GitHub and I hope Updater does the same, if only for the download counters there ;). We make it available on Aminet to make it easy to download using plain HTTP.
As always, I am keen to encourage all developers to make use of AmiSSL. It means users get the latest OpenSSL fixes and CA certs. Developers also gain this feature without have to rebuild their software, which they would have to do if statically linking with OpenSSL (which also heavily bloats their software and memory requirements). The last thing we need is a competing SSL solution - no need to reinvent the wheel (like the MorphOS team decided to do in thier infinite wisdom), with everyone benefitting from one solution instead.
So, with this in mind, I have nothing against it being distributed on Updater too, just as long as AmiSSL is never misrepresented as being an AmigaKit/A-EON product (or indeed a Hyperion product!). Now being open-source, the AmiSSL license does not prevent this, obviously. To be honest, the only weird thing is this thread - surely when users run Updater (or AmiUpdate), they will see there is an update for AmiSSL, or any other software, so really no need to announce it here too!
As far as A600GS is concerned, I am still looking for somebody to work on 68K asm optimised code in AmiSSL. It currently only has very limited optimisations, compared to PowerPC. AmiSSL could greatly benefit from the increased performance that 68K optimised AES and SHA would bring, for example.
|
|
|
|
|
|
Re: SAm469 LE sudeden network drops
|
|
Just popping in
|
I found a thread elsewhere where it was said the issue happens with the OEM IBrowse 2.4 supplied with OS4 - can you confirm that too?
If this is the case, the persistent connections setting shouldn't be a factor. It got me wondering what happens if you set the thread priorities to 0 in the IBrowse network settings? By default, they range from -1 to -3, IIRC. Perhaps this could be causing a race condition with the network device driver.
|
|
|
|
|
|
Re: SAm469 LE sudeden network drops
|
|
Just popping in
|
You could try switching off persistent connections in the IBrowse network settings. Not an ideal solution, but if this helps, it probably points to a bug in the device driver for your network card. There were a couple of reports like this for OS3, but so far nobody has pinned it down to anything.
|
|
|
|
|
|
Re: SAm469 LE sudeden network drops
|
|
Just popping in
|
@Isense
Which version of IBrowse? Does it happen with both 2.5.9 and 3.0a? If you still have the original IBrowse 3.0, be sure to update to 3.0a.
|
|
|
|
|
|
Re: updating sgit
|
Posted on: 12/17 11:10
#5
|
Just popping in
|
I guess I should have left it running longer. I was cloning to the ram disk, but mine stops at around 6% with this error:
libgit error (12): SSL error: received early EOF(64490/1267719)
Seems like Github is terminating the connection for some reason, which may or may not have something to do with the old OpenSSL version that sgit uses.
|
|
|
|
|
|
Re: updating sgit
|
Posted on: 12/16 14:16
#6
|
Just popping in
|
@Raziel
AFAIK, sgit doesn't use AmiSSL, so it is irrelevant looking at that. At least, the version I have is directly linked against the 7 year old OpenSSL 1.0.1u.
For me, the github clone command still works fine, but it could be that I get connected to a different location (to a server that has not been updated yet).
|
|
|
|
|
|
Re: IBrowse 3.0 released
|
|
Just popping in
|
@LiveForIt
"avail flush" doesn't expunge libraries anymore. If you overwrite or rename it, an expunge attempt will be triggered.
The AmiSSL libraries need to maintain an open ElfHandle so that a copy of the data segment can be made for each opener of AmiSSL. With elf.library before 53.35, this meant a file lock too.
|
|
|
|
|
|
Re: IBrowse 3.0 released
|
|
Just popping in
|
@klesterjr You'll be waiting a long time - there is no typo  It is different on OS3 - you can just overwrite libs even if they are loaded into memory and in use. Due to some very boring details, when the AmiSSL libraries are in memory on OS4, the libraries have file locks on them, so the installer can't simply copy the new versions over them (object in use error). So, the installer does some tricks to flush the libraries from memory, so it can then copy the libraries over. But, if something is still actually using AmiSSL, this can't happen, hence the error. This is/was a limitatation of elf.library and I have rewritten the code there to fix this, but this hasn't been publically released yet, although has been supported in AmiSSL since v5.6.
|
|
|
|
|
|
Re: IBrowse 3.0 released
|
Posted on: 11/30 23:10
#9
|
Just popping in
|
@eliyahu
Yes, sorry, the installer doesn't yet take care of any custom images you may have specifying in your settings :(. It is quite tricky to deal with, but I should have at least mentioned it in the installer, so users like you know that they will need to copy them to your 3.0 drawer manually.
No issues have been raised regarding AmiSSL - it sounds like an installation issue. @jabirulo listed the correct libraries, if you have v3, v4 and v5 all installed. It is critical that amisslmaster.library is v5.12.
|
|
|
|
|
|
Re: IBrowse 3.0 released
|
Posted on: 2023/11/22 18:14
#10
|
Just popping in
|
@daveyw Quote: daveyw wrote:BTW, had a slight hiccup when I upgraded from 2.5 to 3.0. The installer detected the version bump, and created a new directory for 3.0 and migrated files across. But I had some custom buttons that I had custom images for. These sit in the same dir as the other button images but for some reason were not migrated. So when I first started 3.0 I got a bunch of missing images error messages. Took me a few moments to figure out what went wrong. Installer should copy across the entire directory including any images I have added. Yes, I did ponder heavily over what to do in cases like this - I should probably have mentioned in the installer that you'll need to copy over any custom images manually, just as you installed them originally. The thinking was that some users may either not have installed any custom images or may have a load of junk in there. Those who upgraded their installs from a 2.3 or earlier install, this will be especially true - they might even have the old pre-2.4 imageset installed still (it bugs me when I see people posting screenshots with those old images, which we already changed 17 years ago!). If this is the worst thing to go wrong with the 3.0 release, I'll be very happy  . Certainly, this is something I can revisit for 3.1, to see if I can come up with a better solution, although obviously it is too late for those who already upgraded.
|
|
|
|
|
|
Re: IBrowse 3.0 released
|
Posted on: 2023/11/20 12:39
#11
|
Just popping in
|
@daveyw Quote: daveyw wrote:
So does this mean IBrowse 2.5 dev is ended, and all future work will just be on 3? Yes - it is time for a fresh start after 23+ years, don't you think? . The original plan at the time (20 years ago!) was to be merging IBrowse 2.4 back onto the IBrowse 3.0 development branch. But the 2.4/2.5 branch diverged so much, and in some ways superceded the old 3.0 code, I had to do things the other way around - I manually merged all the missing/relevant changes from 3.0 onto 2.5.8 (2.5.9 being an unforseen emergency minor update), along with completing the new HTML parser (which Stefan had started, but only really the framework design was done). With 2.5 development, I had become a little bit scared to do too many big changes in 2.5, since I knew it would make merging with 3.0 infinitely worse. Now there is a new unified baseline. The new HTML parser was written with CSS in mind, and the plan is to further adapt this to support CSS (which means big changes to the layout and rendering engine too, amongst other things), which will hopefully be added incrementally in future 3.x releases. Some work was already done for CSS, but the code is not currently used/enabled. I know CSS was planned, 20 years ago, for the original 3.0 release - that is why I decided to make 3.0 a free upgrade for those who have already paid for the full 2.5 release.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/11/13 21:39
#12
|
Just popping in
|
@kas1e Quote: It looks like then that elf.library have 2 mechanism of binaries loading : one for pure binaries (where it possible to have .text and .rodata in one segment) and one when you load .so, where it not possible to have .text and .rodata in one segment. That correct ? 2 different pieces of code for 2 different scenarios ? The first thing that happens is that the program headers are loaded and normally each segment is then loaded in its entirety. Only if an executable segment contains a .rodata section will that segment be handled differently (the segment is not loaded, but instead it is deferred - when a section from that segment is required, that section is then loaded into a separate block of memory). It had to be done that way for all the reasons given. Quote: But then, why there were 2 different ways done at all ? For what benefits ? Why not make .rodata be separate for both types of binaries, and be done with it ? Simple code, simple understanding, everything the same for both types, no "wtf". Or there is some real benefit to have 2 different ways of handling .rodata thing ? @MightyMax Quote: So the best solution would be to always have .rodata section in its own segment ,
regardless of the type (executable, sjobs). This the elf.library allocate straight a head memory as described by the segments. No fancy splitting needed. And sjobs works, too. Yes, probably - maybe there is a good reason as to why not, but from first glance I can't see why it would cause any harm, other than increasing the size of the binary, a little. Why did the old binutils not do this? You'd have to ask whoever decided that. Probably nobody thought this would be an issue at the time, when OS4 did not support sobjs at all. As I mentioned, the 68k cross calls in early code will have been put in .data (as that's what fdtrans originally did) and if it stayed that way there wouldn't have been any of this mess with .rodata. Presumably switching from asm to C for the cross calls influenced them ending up in .rodata instead of .data (mimicking what idltool had been doing since day one). Again, at that time (2005) probably sobjs did not exist in OS4, so nobody could foresee this being an issue. Obviously, there will never be getting away from elf.library handling .rodata in 2 different ways, as old binaries will always have to be supported, no matter if newer ones put .rodata in a different segment.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/11/12 12:08
#13
|
Just popping in
|
The M68k->PPC cross calls that fdtrans generates used to be asm only, and old versions put them in .data, but this was changed to .rodata at some point. Later an option was added in fdtrans to generate them in pure C (idltool can also be use to create the same) with the cross calls declared static const, so those end up in .rodata too.
@kas1e
1) No
2) It doesn't - the .rodata issues affects all binaries. It's just that the solution used for non-dynamic objects cannot be used for dynamic objects (otherwise 24-bit PC-relative jumps in .plt could be out of range, resulting in ISI crashes, which was the case with some of alfkil's elf.library changes, which I have since fixed - I experienced this with the example code that you sent me, which can manifest itself as seemingly random crashes depending on whether .plt ended up in memory in range of .text or not).
3) Yes
What Joerg says is correct. It does indeed matter that .rodata must be allocated into non-executable memory in all cases, whereas .text (and .plt) must go into executable memory. This is not GCC specific and this is what elf.library ensures. For static objects, it doesn't matter much about .rodata, as elf.library will not load any segment containing .rodata (each section is allocated to a separate block of memory, to ensure .rodata is not placed in executable memory). For dynamic objects, that solution will break .text/.plt interaction, hence .rodata must be kept separate from .text/.plt in this case.
With VBCC, it can generate mixed PPC/68K binaries (e.g. for WarpOS), but if you're using the m68k VBCC to compile the m68k code, obviously VBCC knows which code is which and the object formats are different of course. Vlink is nice because it knows about m68k, PPC, HUNK and ELF, unlike the GCC linker which is compiled for a specific target. Don't get mixed up with VBCC generating m68k code and GCC/VBCC genarating PPC code which may contain m68k code (assembly) as data (which is what EmuTraps are). VBCC will put EmuTraps in .rodata, just as GCC does.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/11/10 10:45
#14
|
Just popping in
|
@kas1eQuote: But we talk only about shared objects when talking about .rodata needs to be out of the segment with .plt, right ? When it's pure executable, it still can be together with .text segment with no problems then (like it was with old binutils). That's correct, yes. For the reasons that @joerg has outlined, the special handling of .rodata by elf.library cannot be changed. Quote: But this behavior (having .rodata together with .text in one segment) seems to be varied from different binutils versions: sometime it was with .text, sometime in some version it was out (we found some google links where ppls curious about). For normal executables, I have only ever known .rodata to be put together in the same segment with .text, at least with all the native official SDK compilers (and even all the unofficial adtools ones I have used), and least from 4.0.3 and up. Famous last works, but it probably won't do any harm if .rodata is separated from .text in this case too. For shared objects, it may be different - it's perhaps at least partly the reason why there were two versions of shared objects (I don't know the details, but I don't think PLT worked in the old versions - the old version has been obsolete for quite some years).
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/11/9 17:50
#15
|
Just popping in
|
@joerg Quote: The m68k cross calls probably depend on IExec->IsNative() returning FALSE for the m68k code, just like it's required for utility.library hook functions for example checking if the hook function is PPC native or m68k code.
If .rodata is in the same segment as .text .rodata with the m68k code may be put into executable memory (segment registers on G2/G3/G4 CPUs) making it fail by IExec->IsNative() returning TRUE for m68k cross call code. I guess we are talking purely in the m68k->PPC direction, in which case the only situation an ELF binary contains any m68k code is from the EmuTrap stubs as generated by idltool/fdtrans, etc (fdtrans used to put these in .data, but now puts these in .rodata). I'm not sure where Petunia fits into things, as I couldn't see any code related to this at first glance, the emulation in the kernel performs a check similar to IExec->IsNative(), so I think you're right. Any OS3 code will fail to work on OS4, unless the EmuTraps in OS4 libraries/devices have been loaded into non-executable memory. Not much to be done about this, I guess. In theory, you could load the entire .text/.rodata/.plt segment in one block of memory and then change the memory attributes for the .rodata section, but I don't think it can be guaranteed that there is suitable padding/alignment either side of .rodata, particularly with the older binutils. That said, this could be checked and handled differently if alignment is correct, but perhaps not worth the effort.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/11/9 15:29
#16
|
Just popping in
|
@kas1e Quote: kas1e wrote:
Previous you note that:
Quote:
Yes, .rodata must not be in the same segment as the .text/.plt segment.
Can you please double recheck that ? I mean, what the reasons for and why it should be moved out ?
I can understand why .plt should be the final one (same as .bss) probably, but why .rodata should be not in the same segment ? It can be just before .plt, etc, in same write protected segment ?
Or there something special about in elf.library about ? Did I not already explain it? I hope I did, but perhaps I didn't . I've checked the sources again, as I forgot why... It doesn't matter which order .text and .plt are in at all, just as long as they are both in the same segment - elf.library will load this segment as-is. If you put .rodata in the same segment as .text/.plt, then this triggers elf.library to load .text/.plt/.rodata individually into separate memory blocks (this will break the PLT) rather than loading the complete segment into a single memory block. The logic is that any segment containing .rodata is treated differently by elf.library - each section is loaded individually, rather than the entire segment. The reason: something to do with not breaking 68k cross calls, which is the only clue given in the comments (I haven't figured out exactly why this is, only that the OS crashes if I remove this behaviour). If at all possible, I'd like to change this, but until I understand it, I can't touch it.
|
|
|
|
|
|
Re: Updater tool: latest releases and updates
|
Posted on: 2023/10/27 14:52
#17
|
Just popping in
|
@Maijestro Quote: he he yes you are of course right the updates were provided via both updater (Ehancer Software) and AmiUpdate, it is indeed a bit confusing. I assumed that both tools use the same update server. Thanks for the hint. AmiUpdate is officially supported by AmiSSL - AmiSSL updates go live on AmiUpdate within minutes of me releasing an update
|
|
|
|
|
|
Re: can anybody explain about current situation with BREL Relocations ?
|
Posted on: 2023/10/4 15:00
#18
|
Just popping in
|
@kas1e
There's no such thing as as simple test case for this, but I can come up with something when I have time. A proper test case will need to make use of IElf->CopyDataSegment() to fully cover all eventualities.
As mentioned earlier, maybe once baserel is working again, perhaps that code could be adapted to make it possible to define functions where r13 can automatically be saved/restored (like __saveds) for when using -msdata instead of -mbaserel.
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/9/30 18:27
#19
|
Just popping in
|
@kas1e Thanks for your tests - glad to see the results are all as expected. It's not related to shared objects, but there is also the issue with executables where stdio in destructors is not working in newlib (works in clib2). I have reported this bug, but as nobody fixed it yet, I tried to myself and haven't figured out how to compile it so far. I'm fairly sure a public elf.library update will happen without too much trouble - it was just that it wasn't impossible to do so with the bugs added in v53.35-53.42 (and yes, one bug was my doing ). Ideally, I "just" need to clean up the reloc routine by rewriting it - Alfkil's pointer equality fix, for example, results in an unnecessary duplicate dynamic symbol lookups when processing solibs. And then there is the bolted on symbol cache that was added at some point, which is now not used everywhere it could/should be. Performance should already be better with elf.library since v53.45 (for example, Odyssey loads here in 5 seconds, instead of 7).
|
|
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/9/30 11:27
#20
|
Just popping in
|
I released a new beta version of elf.library (53.49) yesterday, which should now behave properly if st_value is 0 or not, for undefined functions. This doesn't include my rewrite of all the reloc code, as I've not completed that yet.
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
