On 27/09/2024 10:03, David Brown via Gcc wrote:
> On 27/09/2024 10:13, Dennis Luehring via Gcc wrote:
>> Am 27.09.2024 um 09:56 schrieb Jonathan Wakely:
>>> On Fri, 27 Sept 2024, 08:39 Dennis Luehring, <dl.so...@gmx.net> wrote:
>>>
>>> > Am 27.09.2024 um 09:34 schrieb Jonathan Wakely:
>>> >
>>> >
>>> > > They might not have
>>> > > been using the original gcc-3.4.0 sources.
>>> >
>>> >
>>> > seems to be very possible
>>> >
>>> >
>>> >
>>> > > There should be no need to edit those files, but that doesn't mean that
>>> > the
>>> > > people who built your old toolchain didn't edit them.
>>> >
>>> > the other way would be using --with-multilib-list=list ?
>>> > but that usage should be visible by using -v on the original build, or?
>>> >
>>>
>>> I think so yes, but I'm not sure. If you said arm-elf in the mail Subject
>>> you might get the attention of somebody who knows the details.
>>
>> so just repost with a changed subject?
>>
>>>
>>> Have you tried to obtain the sources from whoever provided the original
>>> compiler that you're trying to replicate?
>>>
>>
>> so far not available - the original providing company (Microcross) is
>> long defunct (over a decade now)
>> but im still trying to reach someone
>>
>
> It was very common at that time for suppliers to use slightly modified gcc
> sources for microcontrollers (especially ARM, but also for other targets).
> Typically manufacturers and some major third-party gcc builders were ahead of
> mainline in support for some microcontroller cores and workarounds for known
> hardware bugs, and they also often backported such changes from newer gcc
> mainline to older gcc releases. So there is a very real chance that the
> sources you have are not original.
>
> You could download the archived release from the gcc website and compare the
> sources to get some idea if they have changed.
>
> And if you don't get hold of someone from Microcross, you might have luck
> with someone from Code Sourcery. I believe they were doing a lot of the work
> on ARM gcc on behalf of microcontroller manufacturers at that time.
>
> David
>
>
The list of multilibs for Arm has become increadibly long as the architecture
has migrated down the different (A, R, M) profiles. To handle this we now
provide some canned rules to build a set of multilibs that will handle most of
these profiles out of the box, but they can increase the overall build time
significantly, and only work correctly if you don't try to override the default
architecture flags, or change the default code generation from Arm to Thumb.
You can enable all this if you add
--with-multilib-list=<list>
where <list> can be any of "aprofile", "rmprofile" or "aprofile,rmprofile".
You can also see the code that supports all this (and how complex it is :) ) in
gcc/config/arm/{t-multilib,t-aprofile,t-rmprofile).
All this is with the latest sources, but this code dates back several releases
now.
HTH,
R.
