gcc 9 and 10

Quote:
It can be a bit confusing to patch patches and work with two repos at the same time (the adtools repo and the submodule in binutils/repo). But it's a pretty nice setup. Once you've done gild checkout binutils you can start working on the binutils/repo. After the checkout that repo will be in the middle of a merge session. You'll need to fix all conflicts and run git am --continue, then you'll get new conflicts, fix them, repeat until all conflicts are gone. If you look in the commit history when you're done, you'll see that all patches are there as separate commits. If you need to fix additional things after all patches are applied, just create a new commit. When the binutils repo is in good shape, run genpatch to regenerate the patches. If you did additional commits, patches for those will be created in the patches dir belonging to your new binutils version. Then you need to create a commit in the adtools repo containing all the new patches. That's the commit you make a PR out of.

Quote:
Yes, I see no reason to keep them.

Quote:
I don't think we should hide warnings with CFLAGS. They might be valuable and fixing them isn't much work.

Quote:
There are some documentation fixes if I remember correctly and I think those are nice to have. Ideally it should be possible build a reasonably polished SDK from adtools IMO. I think we can skip 68k, it will still be possible to build older versions with 68k support using adtools. If we want up to date 68k support in adtools we should look into bebbos work anyway.

These are just my opinions though. Sebastian has the final word. Creating a PR is a good way of getting feedback :)

@sTix
Wrote you mail about all that git issues to clear up some things.

Anyway, I also tried to patch Binutils 2.29.1 (that one where dwarf-5 were added), and this one is a little bit more different than just 2.24: elf32-ppc.c (which is mostly a full copy for our elf32-amigaos.c with some changes) were changed more, functions names, the functions itself, etc. So that will need some additional (but still not hard one IMHO) work.

But i think we better move version by version of the course as you say, as we will fix things step by step, and that will be surely easy.

I also wrote a mail to Sebastian, asking if he ok with removing, for now, morphos/amithlon from patches as they of now use anymore by anyone in morphos, and amithlon is amithlon.

Yes 2.24 to 2.29 is a big step. Not much inflation in binutils land. They've only reached major version 2 in 30 years :)

Can you forward the mail to rolfkopman <snake like a> gmail <dot> com?

@sTix
Mail sent.

ps. received a mail from Sebastian, he says that he of course agreed to remove Amithlon and Morphos, as while adtools were started years ago as cross-platform for everyone, today that isn't the case anymore, so we can concentrate on os4 stuff. Now I just need to get familiar with all that gild patching mechanic and can make a proper 2.24 replace

@kas1e

FYI: I bumped gcc to the latest release, 11.3.0 (pending PR and test build).

@sTix

Quick test with ScummVM shows it's working (no full build yet due to ScummVM source bugs).

Thanks a lot

@sTix
Has gcc 12 been released beyond the base release?

C++ is nearing 2023 release so gnu/gcc might wait for that to release 12.1 ?!

@Raziel

Nice!

@trgswe

It looks like it will take a couple of months before gcc 12 is released: https://gcc.gnu.org/develop.html#timeline

@sTix
found gcc 12 at https://gcc.gnu.org/gcc-12/changes.html
do note that there are changes especially for PPC, some C++-23 additions, and C2X additions, supports two new debug formats CTF (should be smaller, faster etc.) and BTF (only for linux kernel), anazlyzer got a workover, removed some bugs in c++ and libstdc++.

It should have been released in april, it is now at stage 4, so it most likely is tied to C++-23 for release of 12.1.

@kas1e

Quote:

That patch only fixes syntax errors in the 'texi' files, provided by the Port for documenting
the support for the hunk object file format. thus can be ignored if going for a OS4 only target
binutils. Even the added amiga.texi amigalink.texi files can be omitted, like the modification
on other texi files.

BTW you could check these files, if you generate the documentation, which as long i know isn't auto,
automatically generated during an 'make install' call.

@All
Just to let you know, MightyMax progress till the moment that we have latest binutils creating working os4 binaries (via asm + ld), check this out:






And binary works on os4.

@kas1e
@MightyMax

Very nice. Good job!

great news indeed... Awesome work guys

@kas1e
Quote:That may be a problem, post a more detailed output of readelf, for example "readelf -e test_new".

@joerg
As far as we find, its issue introduced since v2.39 of binutils:
https://stackoverflow.com/questions/73 ... ions-embedded-arm-project

To disable this warning, we just use --no-warn-rwx-segments , which we can make a default one later (if it indeed harmless error).

But anyway, just for sake of, there is "readelf -e test_new" output:



And that is "readelf -e test_adtools" (i.e. the one compiled with current adtools's binutils):



Seems both about right ?

The only differences i see now, is that we do not have ".eh_frame" at all, and that shstrtab, symtab and strtab are of different order (but that can be easy binutils construct binaries a little different now). Through missing ".eh_frame" probably can be an issue.

@kas1e
Quote:.text must not be writable.
If elf.library ignores it for code it may not be a problem, but if it doesn't and allocates the code in writable memory it's a problem.

Quote:Read-only (.text, .rodata, ...) and writable (.sbss) sections mustn't be in the same segment.
Executable (.text) and non-executable (everything else) sections mustn't be in the same segment either.

Quote:Which version is that?
binutils 2.14.x was working, everything newer: unlikely.

@joerg
Default adtool's one is 2.23.2. So that how it for us for last 10 or more years. Maybe even 15 or more, because 2.14 one were tooo long ago, and everything we had today build with 2.32.2 binutils and GCC starting from 6.x.

Anyway, if you're in interest to help with advices, etc., take a look please on that one:

https://github.com/migthymax/binutils-gdb/issues/2


@all
Was able to build Frederik's SSHTerm with new binutils, and it's working ! This is the first C-based test case, with amgiaos4 specific code and with usage of .a link libs, amissl and stuff. This mean that basics at least works!

@kas1e
The original AmigaOS 4.x port of binutils (2.14.x) was working without any problems, but then ADTools was changed to an utter nonsense mix of 3 incompatible OSes (AmigaOS 4.x/PPC, AmigaOS 3.x/m68k and MorphOS) which destroyed the required AmigaOS 4.x specific features.

Quote:I don't know if the default for the AmigaOS 4.x port of strip was ever changed, but 15 years ago on AmigaOS 4.x only using "strip --strip-unneeded" worked.

@joerg
At least now, we do not add any OS3/MOS code on top of binutils 2.40, only os4 specific changes (you can see it in the Max's repo).

Through, what you mean by "working without any problems” ? So far, the current binutils from adtools working too :) (at least to the level most of us need:))

@joerg

Strip -s works fine for me.