@kas1e

Yes, .rodata must not be in the same segment as the .text/.plt segment. Also, .text and .plt must be placed together in the same segment - it shouldn't matter where .plt is in the segment, just as long as the branches into the PLT are correct.

Obviously, .rodata should be placed in read-only segment, not a writable segment - it doesn't need to be executable.

So, with your "rodata_rw" test case, what exactly is the issue? Here, with elf.library 53.42, I get the output:


Slightly curious that the output from the dtors functions does not appear, yet with ELF.debug set to 1, it is clear that it is running the dtors functions.

Having modified elf.library to always load the .text/.plt segment in one go, rather than each section separately, the OS won't boot, so looks like I won't be changing that behaviour . Perhaps could be an alignment issue, although not really sure - in both cases, .rodata is marked as read-only, as you would expect.

What matters is that the behaviour was specifically changed to load the .text/.plt segment in one go, mainly to make the PLT stuff work for dynamic objects. So, we know what the correct thing is for binutils to do now.

If there are still issues with ctors/dtors not working, even when .rodata placed in a separate read only segment, I'm happy to check the relevant code in the latest elf.library (I believe Alfkil changed it so that it calls the ctors/dtors directly, right?). Just point me in the direction of a compiled test case, so I can reproduce the issue here.

@kas1e

Yes, I'm using your test case that had .rodata in the same segment as .text/.plt. This was perfect to exactly understand what was really causing elf.library to crash the code. It had nothing to do with .rodata being in a writable, read-only or executable segment. It was simply the placement - for dynamic objects, .rodata must not be placed in the same segment as .text/.plt with the current elf.library. As you say, .rodata should obviously be read-only. That must be why the old binutils did it that way.

However, I'm pondering whether elf.library needs to do this anymore. So far, I'm struggling to understand what the original reason was, so reluctant to change anything. The change happened in elf.library 53.4:

Quote:

Annoyingly I had early ignored "Ignoring this program header because we have an .rodata segment" in the debug output, which you'll see with ELF.debug set to 1, thinking it wasn't relevant. But, this would appear to be the reason for the behaviour I described in my previous message. That is why it works fine when .rodata is in its own segment, because then the segment containing the .text/.plt sections is loaded into a single block of memory, making the PLT branches correct.

Why does elf.library need to do this - to make 68k cross calls work, according to the comments (need to do some more research to understand this!).

So, does the old binutils always put .rodata in its own segment for dynamic objects? I'm sure .text and .rodata have always gone in the same segment for normal non-dynamic stuff.

@kas1e

I'm afraid I don't have the time to start compiling binutils, so I'm just using your example files that you posted to the beta list.

@MigthyMax

You're right, of course - serves me right for starting to look at this late at night! I've traced through the PLT setup and it does actually look to be working correctly. Instead, the problem appears to be that elf.library is allocating and loading all the sections in segment 1 separately (which includes .text, .plt and .rodota), which I haven't quite figured out yet - it only seems to be seeing the data segment during these searches. The end result is that because R_PPC_PLTREL24 relocs are intentionally ignored, the in place branches jump to the wrong address. For it to work .text and .plt must be located in the same block of memory, so the offsets to the .plt jump table are correct. Just trying to figure out why this isn't happening.

The PLT jump table is created at load time, with the jumps poked into the table when R_PPC_JMP_SLOT relocs are resolved (after other necessary objects have been loaded). The jump table is part of the .plt section, which the fixed branches in .text point to. I don't think the problem is directly related to this now.

@MigthyMax

Fortunately, I can build elf.library and add extra debug to try to figure out what is going on...

I'm not an expert on dynamic objects, but looking at the .rela.plt section, all the R_PPC_JMP_SLOT symbol values are 0 (readelf -r) with the new binutils. The elf lib uses these values to calculate the "real address", which it then puts in the PLT. I don't think they should be 0 - they need to point to the location of the respective function in .text (at least, that's the case in libc.so).

The elf.library relnotes in question appear to indicate that there may have been special modifications to binutils to make the PLT work:

- R_PPC_PLTREL24 relocs are now ignored for version 2 shared objects, since the
jumps are already correctly targeted at the PLT entries.

- R_PPC_JMP_SLOT relocs now correctly update the dynamic symbol table. On top
of that, the original PLT setup is no longer written here but rather when
setting up the PLT section.

- Lazy binding works now that the PLT is actually used. Note that for all of
the above to work, the latest binutils are required.

This is all from 2009.

I might be wrong, but it looks like the puts@plt jump is not targeted at a PLT entry.

@kas1e

Here it is crashing when calling the .ctors functions. I've double-checked all this by disassembling and peeking at the crashed code in memory and it seems .ctors is being relocated correctly. Although the crashlog might not always indicate it, it looks like it is the puts@plt call which crashes, because that jumps to the wrong address due to the reloc not having been applied. R_PPC_PLTREL24 relocs are always ignored by elf.library (there's a note about it in the relnotes).

I'm not up to speed with shared objects, so my question is where should the jump offset be corrected? Is this something that elf.library should be doing or is the wrong code being generated by the compiler?

Certainly, I've not seen any crashes that indicate that .rodata is being written to, so it is probably related to the physical position of .rodata - relocs will be different then too.

(apologies for the heavy re-edit - hopefully, nobody read the first version )

I'd say .rodata being writable may be a red herring. Does the output before the crash, with "setenv ELF.debug 1", give any clues?

Quote:
Of course, nobody should take my word for it - however, "readelf -l" on most (if not all) OS components will show this to be the case. Two segments, unless there is no rw data at all, in which case a single read-only executable segment (e.g. "C:Version").

@kas1e

BTW, I know it was only test code, but you should never put data in .text, even if it is read-only. Otherwise, the LTE is likely to bite you and mangle it (I found this out the hard way in OpenSSL).

I don't think anything dumps all sections into a single segment does it? What does "objdump -ph" say?

AFAIK, it has always been the case that, at least from 2005 or so, that compilers will generate two segments. That's what happens with GCC 4.x, 11 and VBCC, at least. The first segment contains .text and .rodata (physically marked as read only when loaded - anything that writes to this segment will cause a GR) and the second contains all the other data sections (.data, .bss, .sdata, .sbss, .ctors, .dtors, etc). If there are other versions of GCC that do dump all code and data into a single segment, then that would be an incorrect thing to do.

Regarding IElf->CopyDataSegment(), as the name suggests, it copies the entire data segment (not only .data and .bss). How does it know which segment is the data segment? The original elf.library used the segment containing the .data section, whereas the latest elf.library additionally looks for .bss, .sdata and .sbss too (in case there is no .data section). I use IElf->CopyDataSegment() with both -mbaserel and -msdata.

I've not tried it, but if there were truly only a single segment containing both code and data, probably IElf->CopyDataSegment() might still work. However, it would obviously be suboptimal unnecessarily copying all the code too each time.

A little OT, but I almost forgot, AmiSSL is also restricted to GCC 4.x because it heavily relies on -mcheck68kfuncptr, which I think Stefan Burstroem added, but it never made it into newer releases. This is required for 68k programs to be able to use AmiSSL PPC because OpenSSL uses many function pointers which are user definable. The -mcheck68kfuncptr feature caused function pointers to be checked if they were 68k or PPC code, automatically running it via emulation if 68k.

I'm a little late to this thread, but thankfully @joerg has explained most things. He and I are probably only two of a handful of developers who used -mbaserel - IIRC, both OWB and Timberwolf use it. IBrowse 2.5 used to use it, but I switched to using -msdata instead...

One of the good things about -mbaserel is that the compiler allowed developers to easily restore r2 for library interface functions, for example, like __saveds did on OS3. There is no such thing for restoring r13, so you have to do the r13 save/restoring manually using asm instead.

AmiSSL is likely to always use -mbaserel because although the data size that OpenSSL uses is not yet 64K, its getting close and will no doubt go over that limit in the future. It is not feasible to patch OpenSSL to use less data.

GCC 4.0.4 (available as native and cross-compiler) was the last version to fully support -mbaserel and generate the correct code, hence why we are stuck with it for AmiSSL. IIRC, the linker and binutils from 4.2.4 did also handle baserel correctly, but the compiler itself created broken baserel code.

Libraries and startup code use the elf library CopyDataSegment() function to copy and relocate the data segment (segment, not section) and FreeDataSegmentCopy() when done with it. These functions were slightly buggy until I fixed them in V53.35.

Not to bore you with the technical details, but AmiSSL needs to maintain a file lock on the libraries with the elf.library 53.34 or older. The installer tries to expunge the libraries from memory, but this can only happen once all applications have closed it.

When the latest elf.library finally gets a public release, this shouldn't be a problem any longer, as AmiSSL no longer needs to maintain locks on the libraries in that case.

Would be interesting to find out which application is causing trouble. If you use something like Scout, you could at least see how many applications have the libraries open currently. It could indicate that an application is maybe failing to close AmiSSL properly on exit.

It is all very well trying to fix the JS to make the Cloudflare check code work in Odyssey, but IMHO it is more important to figure out why Cloudflare is serving this page to Odyssey in the first place. It is likely to have absolutely nothing to do with JS, but will be related to the HTTP headers that Odyssey is sending and the HTTP connection mode. Obviously, Cloudflare is flagging these as suspicious for Odyssey, but not for IBrowse.

It is completely safe to use Cloudflare to serve Amiga related sites, since it is highly configurable. These bot blocking checks could be switched off via a rule for Odyssey, and other Amiga browsers, for example. Obviously, non-Amiga sites are not going to want to do this.

@walkero

One of those limitations is Gemini support - it is disabled in the demo version of IBrowse.

@msteed

Those features can be switched off or adjusted globally, and also via page rules (where, for example, you could disable them using a user agent match). That said, I don't think I've ever stumbled on one of Cloudflare's captcha pages using IBrowse.

However, with Cloudflare I'd be more concerned about how much bandwidth OS4Depot uses. Cloudflare could reduce the bandwidth uses at the hosting provider, but sometimes object to sites serving a lot of large static files and cancel accounts because of it (even paid subscriptions).

Most hosting providers offer Let's Encrypt certificates free of charge - it is a feature built into cPanel, for example. So, that would be the easiest solution. Cloudflare takes a fair bit of learning to get the best out of it.

@msteed

Quote:
Um, check the IBrowse website's certificate - it has been behind Cloudflare for some time. Needless to say, it works fine in IBrowse, otherwise we wouldn't use Cloudflare.

Shouldn't cost anything at all if using Let's Encrypt.

@white

Not going to work, I'm afraid. It appears to rely unnecessarily heavily on JavaScript, failing even at the first hurdle. If you check the source code in IBrowse it attempts to redirect the page by setting window.onload, which IBrowse doesn't yet support. It could be done using meta refresh instead, or by setting the onload attribute in <body> (which was the "classic" way of using onload).

That said, even with that working in IBrowse, I fear it may then display the site, but nothing much else would work due to the heavy JavaScript usage required (for example, to read user input).

So, for now, not much that can be done. Perhaps there are other solutions out there. Privoxy is the only one that I remember from days gone by.