Binutils port

I'm started to apply all the patches from the binutils adtools ports to the current main development
trunk of the binutils. For that I setup a temp. repository ongithub.
I tried to only take over all changes that are needed for AmigaOS ELF. Omitting Morphos, AROS, AmigaOS
Hunk.
Because there are parts which changed a lot I had more or less manually apply all patches. Some patches
weren't needed any more, others were straight forward, and others hat to be adapted in that way, that they
merely are recognizable anymore.

Id doesn't compile yet, mainly i have issues to adapt the apaches for obycopy.c and the build system for
the gas part. Maybe someone can help?

The flowing patches haven't been yet manually applied, because I'm unsure if they are really still needed:

* 0010-Fix-Wimplicit-fallthrough-warnings.patch

Mainly because the most of them just change the comment, but some even add break statement, which might have
unwanted side effects,

* 0013-Don-t-emit-dynamic-relocations-for-data-symbols.patch

I'm unable to match it with the new structure of the binutils.

@MightyMax
That's a big project and quite necessary for us. Thank you so much for doing so.

Wouldn't it be easier to start with the adtools version and gradually update it to newer versions?

@MigthyMax
Sorry, can't help directly: i once tried the latest one to port and find out it changes quite heavy. That why my plan was version by version update it, so i will not to have massive changes right from the start, as they may differ pretty well.

At least version by version you will follow the logic of their changes, and issues will be not that massive

ps. i see your repo called "binutils-gdb", just in case there is my attempt porting newer GDB: https://github.com/kas1e/gdb

It all with proper README, etc. so to not lose time on how-to-configure-it, but it didn't work anyway : it runs, but tracing didn't work. Through may help you for a start if you think about gdb port too.

Quote:

First i thought so too, but somewhere in between they made a quiet mayor changes. So I concluded,
why bother with steps by steps, instead go to the head.

The biggest change is that they changed their inner APIs. In most cases it isn't that difficult
to adapt, as long I understand the stuff actually should do.

One major change is that actually the elf32-amigaos.c file isn't needed anymore. The needed
changes (which aren't that much) can now be completed embedded in elf32-ppp.c. For some changes
I'm really wondering why they are actually needed.

But currently my main issues are to get objcopy.c adopted to the new API. The stuff added to
objcopy.c seem to be related to the feature strip unneeded relocations. But it is hard to reverse
engineer what defines unneeded relocations on the amiga elf platform?

Quote:

I will take a look, but the first aim isn't to port gdb to. My repository is anmed that way,
because the upstream repo, has that name too.

@MigthyMax

Awesome, thanks a lot

@MigthyMax
Thank you so much for your reply. This project is really crucial for us. I'd love to get involved, but I am occupied heavily with the WebKit port. I hope someone else can help more.

@walkero

Maybe answering some of my question would help Anyone else is even encourage to answer if he has insight.

And here comes a question regarding objcopy and the strip options. For amiga elf objcopy has been modified
in regards how --strip-all works. It doesn't strip everything. It keeps mainly the symbols _SDA_BASE_, _start,
_amigaos4_, and some other symbols under some circumstances. This is very specific for amiga, on all other
platforms (as far i have looked into it), the --strip-all option is taken as it is. It removes all symbols,
regardless if it is smart to do so or not.

What I don't understand, why hasn't that functionality been implemented under the --strip-unneeded option,
because putting the behavior under that option seems for me to be more logical. So is there any historical
reason why it is, like it is, or did it just happen to be so, without any deeper thoughts?

@MyghtyMax
I can't say for 100% sure why they choose the "--strip" way, but i think that for the reason to be “ok” with all the makefiles and stuff by default, as most of the time they use "strip" in linux and other OSes. IMHO, it all done just for “Easy porting”.

Also, in terms of how elf files loaded, processed by loader, etc., i wrote a few years ago a big article about, check this out:

https://wiki.amigaos.net/wiki/The_Hacking_Way:_Part_1_-_First_Steps

In the middle i explain a bit how linker works (ld-scripts and stuff), relocations stuff, how the loading happens, etc. In the last parts of the article, i custom-hack the elf binary, to see what sections actually reads, what not, etc. ,etc. Of course, it will not fully cover all you want/need to know, but it should give some answers about some os4 specific basics (i hope).

I wrote this article with help of Frank Wille, so the details in the article are pretty deep.

@kas1e

Quote:

That i thought at first too, but that makes no sense. If if on other OS if you strip-all, you get in 99% of use case
a useless binary. That's why they have --strip-unneeded, i think.

Maybe someone knows a good small program, which can be ported, and makes use of some kind of stripping.

@MigthyMax
Quote:strip had to be changed because initially AmigaOS 4.0 didn't use ELF EXEC but ELF REL, i.e. the object file format, for it's executables and execuables can't work if for example the _start() function or _SDA_BASE_ for the relocations done in elf.library are removed.

IIRC it was required to change the AmigaOS 4.x execubales to ELF EXEC for the shared object support.

Hi, @MightyMax

In your original post you say that you applied the patches manually. The first patch, 0001 is 27k lines long - did you really do this manually without any commands?

Curious, thanks.

There is just no point in going to GCC 11+ without first bringing binutils up to date. Our version, 2.23.2 is now 10 years out of date.

I will work on this myself if I have to, but I wondered if you could provide hints because at the moment I think a manual approach is required; and I find it baffling that you made all of the changes from 0001 manually. If so - well done! I know that you skipped the non OS4 parts too, but that is still a lot of eye straining.

On your branch I see that you applied one large commit, probably up until patch 0010 where you ran into trouble. Because it is one large commit, it is difficult to integrate this back into ADTOOLS. Really, you need to save the diffs per patch, so that you can have a new 0001, 0002 etc.

@rjd324

A new release would be great...