This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?
On 11/25/19 2:43 PM, Andrew Dean via gcc wrote:
>>>>>> I get errors like this:
>>>>>>
>>>>>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
>>>>>> 'rdimon.specs': No such file or directory
>>>>>>
>>>>>> I can see that the rdimon.specs flag is added based on this line
>>>>>> in aarch64-
>>>>> sim.exp:
>>>>>
>>>>> Where does aarch64-sim.exp comes from?
>>>>
>>>> /usr/share/dejagnu/baseboards/aarch64-sim.exp
>>>>
>>>>>
>>>>>>
>>>>>> set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags]
>>>>>> -
>>>>> specs=rdimon.specs"
>>>>>>
>>>>> I think this is for baremetal/newlib targets, ie. aarch64-elf, not
>>>>> for aarch64- linux-gnu.
>>>>
>>
>> Yes -specs=rdimon.specs and other such flags are for use only on bare-metal
>> targets.
>>
>>>> Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or aarch64-linux-
>> elf...
>>>> I get a KeyError in build_compilers and build_glibcs when it tries to look up
>> the config with either of those values.
>>>>
>>>
>>> Unfortunately the build-many-glibcs.py does not have support for
>>> baremetal build yet (since it is a tool created to build
>>> cross-compiling toolchain using glibc).
>>
>> And glibc doesn't work bare-metal ......
>>
>> regards
>> Ramana
> I guess that means that the dejagnu baseboard "aarch64-sim" is only meant to do bare-metal testing? How would one build/test GCC hosted on x86_64 and targeting aarch64 then? Is there a different simulator approach I should be using?
I've used qemu for this kind of testing. In my environment I have root
filesystems with native binaries/libraries. I can just chroot into
those filesystems and qemu handles everything.
In theory one wouldn't even need to chroot into the filesystems if you
set the library paths right.
jeff