Synopsys ARCv3 ISA includes 32-bit ARC HS5x targets and
64-bit ARC HS6x targets. Both CPU families are placed
in "arc64" subdirectories as it done for GCC port.
Target name arc64 is used for historical reasons and
Synopsys ARCv3 baremetal toolchains contain multilib
configurations both for 32-bit and 64-bit families.
arc32 target name is reserved for 32-bit ARC HS5x
targets in case of non-multilib 32-bit builds.
Note that libgloss libraries for ARCv3 are compatible with
libgloss for ARCv1/2. Thus, Makefile.inc for libgloss uses
sources from libgloss/arc directory except crtX.S files.
Co-authored-by: Shahab Vahedi <list@vahedi.org>
Co-authored-by: Claudiu Zissulescu <claziss@gmail.com>
Co-authored-by: Bruno Mauricio <brunoasmauricio@gmail.com>
Co-authored-by: Luis Silva <luis.m.silva99@hotmail.com>
Signed-off-by: Yuriy Kolerov <ykolerov@synopsys.com>
There are 3 families of Synopsys DeisgnWare ARC processors:
ARCompact/ARCv1 (32-bit), ARCv2 (32-bit) and ARCv3 (32-bit
and 64-bit targets). Upstream Newlib supports only ARCv1/2.
This commit prepares ARCv1/2 libgloss port to be reused by
ARCv3 port (except crt* files). Note that __ARC64__ macro
stands for all ARCv3 targets.
Signed-off-by: Yuriy Kolerov <ykolerov@synopsys.com>
It makes it usable with standard symbol names defined in default
linker scripts of the MetaWare toolchain.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
There's no semantic change, it's only to make the same code
compilable with MetaWare toolchian, which actually assumes
@x as a full name, not omitting @.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
.align is supported by both GCC & MetaWare compiler for ARC,
yet implements the same semantics as .balign which only works
with GCC.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
The linker needs to know whether a symbol is STT_FUNCTION when
deciding which farcall stub to emit (if needed), this patch adds this
to the FUNC_START macro which is used in crt0.
These specs files are introduced for EMSK board:
* emsk1_em4.specs - EMSKv1 with EM4 core, everything in
ICCM/DCCM memory
* emsk1_em6.specs - EMSKv1 with EM6 core, everything in
ICCM/DCCM memory
* emsk1_em6_ram.specs - EMSKv1 with EM6 core, startup code
in ICCM and everything else in RAM
* emsk2.1_em5d.specs - EMSKv2.1 with EM5D core, everything
in ICCM/DCCM memory
* emsk2.1_em7d.specs - EMSKv2.1 with EM7D core, everything
in ICCM/DCCM memory
* emsk2.1_em7d_ram.specs - EMSKv2.1 with EM7D core, startup
code in ICCM and everything else in RAM
* emsk2.2_em7d.specs - EMSKv2.2+ with EM7D core, everything
in ICCM/DCCM memory
* emsk2.2_em7d_ram.specs - EMSKv2.2+ with EM7D core, startup
code in ICCM and everything else in RAM
* emsk2.2_em9d.specs - EMSKv2.2+ with EM9D core, everything
in ICCM/DCCM memory
* emsk2.2_em9d_ram.specs - EMSKv2.2+ with EM9D core, startup
code in ICCM and everything else in RAM
* emsk2.2_em11d.specs - EMSKv2.2+ with EM11D core, everything
in ICCM/DCCM memory
* emsk2.2_em11d_ram.specs - EMSKv2.2+ with EM11D core, startup
code in ICCM and everything else in RAM
An example of building an application:
$ arc-elf32-gcc -mcpu=em -specs=emsk2.2_em11d_ram.specs main.c -o main
Signed-off-by: Vladimir Isaev <vvisaev@gmail.com>
Signed-off-by: Yuriy Kolerov <kolerov93@gmail.com>
These specs files are introduced for EM SDP board:
* emsdp1.1.specs - EM SDP 1.1, everything in ICCM/DCCM memory
* emsdp1.1_ram.specs - EM SDP 1.1, startup code in ICCM
memory and everything else in RAM
* emsdp1.2.specs - EM SDP 1.2, everything in ICCM/DCCM memory
* emsdp1.2_ram.specs - EM SDP 1.2, startup code in ICCM
memory and everything else in RAM
An example of building an application:
$ arc-elf32-gcc -mcpu=em -specs=emsdp1.1_ram.specs main.c -o main
Signed-off-by: Vladimir Isaev <vvisaev@gmail.com>
Signed-off-by: Yuriy Kolerov <kolerov93@gmail.com>
An example of building an application:
$ arc-elf32-gcc -mcpu=hs -specs=hsdk.specs main.c -o main
Signed-off-by: Vladimir Isaev <vvisaev@gmail.com>
Signed-off-by: Yuriy Kolerov <kolerov93@gmail.com>
An example of building an application:
$ arc-elf32-gcc -mcpu=em -specs=iotdk.specs main.c -o main
Signed-off-by: Vladimir Isaev <vvisaev@gmail.com>
Signed-off-by: Yuriy Kolerov <kolerov93@gmail.com>
This library implements libgloss input/output and setup
routines for UART 8250 devices of ARC development boards:
* EM Starter Kit
* HS Development Kit
* EM Software Development Platform
* IoT Development Kit
_uart_8250_setup function with proper parameteres must be called
to setup UART 8250 device for a particular board (refer to
a board's documentation).
Signed-off-by: Vladimir Isaev <vvisaev@gmail.com>
Signed-off-by: Yuriy Kolerov <kolerov93@gmail.com>
Use atexit funtion to setup fini routines to be called on exit
instead of filling in __atexit structures manually.
Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
There is a special interface built in ARC simulators (such as
nSIM) called MetaWare hostlink IO which can be used to implement
system calls. This commit adds support for this interface to the
ARC port of libgloss.
Here is an example of using this interface:
$ arc-elf32-gcc -mcpu=hs -specs=hl.specs main.c -o main
$ nsimdrv -tcf $NSIM_HOME/etc/tcf/templates/hs48_full.tcf main
Hello, World!
Signed-off-by: Vladimir Isaev <vvisaev@gmail.com>
Assembler for ARCv2 always extends the name provided by
.file directive to an absolute form.
On ARCv3 targets .file directive forces assembler to put
a provided string to DW_AT_name field as is without
extending to an absolute path. Then GDB cannot find
source files because of it.
The best way to fix this issue is just delete lines
with .file directive in .S files and let the compiler
to decide what DW_AT_name must contain. Particularly,
the compiler fills this filed by an absolute path to
a .S file because only absolute paths are used in
toolchain's build process.
Signed-off-by: Yuriy Kolerov <kolerov93@gmail.com>
According to GCC documentation for ARC, a function marked with
the long_call attribute is always called using register-indirect
jump-and-link instructions, thereby enabling the called function
to be placed anywhere within the 32-bit address space.
exit_halt function is provided by crt0.S and it's used
in nsim-syscalls.c. Thus, we want to ensure that a linkage
issue will not arise.
Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
- The PRU newlib port is supposed to implement case #2 as described in
newlib/libc/include/reent.h . Thus drop the defining of
MISSING_SYSCALL_NAMES.
- libgloss/configure: Regenerate.
- libgloss/libnosys/acinclude.m4: Do not define
MISSING_SYSCALL_NAMES for pru.
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
This patch resolves the following build error which occurs with gcc 14.1.0:
../../.././libgloss/microblaze/linux-outbyte.c: In function 'outbyte':
../../.././libgloss/microblaze/linux-outbyte.c:3:9: error: implicit declaration of function '_write' [-Wimplicit-function-declaration]
3 | _write(1, &c, 1);
Signed-off-by: Neal Frager <neal.frager@amd.com>
The envp paramter is currently NULL when crt0.S calls main.
With this patch the envp parameter should now be set correctly.
Tested with riscv32 and riscv64: both gdb/sim and qemu do work.
Avoid a recursive make to speed things up a bit.
A cr16-elf build shows installed objects & libs produce same code.
The test targets were dropped as they didn't actually work -- there
is no test.o rule in here.
Strip a few more instructions from crt0-minrt.S:
- Remove "halt" and rely on the infinite loop after main()'s return.
- Remove main()'s argc and argv argument initialization. Host loader
does not set them, and typical firmware does not use them, either.
- Remove the __dso_handle symbol.
This should be safe because the default crt0.S is fully standards
compliant. Whereas crt0-minrt.S has been documented from the beginning
to intentionally miss features in order to reduce firmware size, while
still enabling typical PRU firmware to operate.
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
Avoid a recursive make to speed things up a bit. This change was
inspired by the recent similar patch for c6x:
https://sourceware.org/pipermail/newlib/2023/020869.html
While at it, fork crt0-minrt.S into a separate source file instead of
relying on a predefined macro to generate two different object files.
This improves clarity, simplifies the build rules, and would allow
further optimization in crt0-minrt.S to be implemented more cleanly.
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
Wrapping the dir info with @ifnottex means it's included in all other
outputs like html which makes no sense. Switch to @direntry which is
specific for this content and is automatically written to the output
that makes sense, and omitted from the rest.
First off, afaict, xc16x support has never been merged into gcc.
Upstream merge isn't strictly required for new ports, but it seems
like people should merge eventually in some shape, and considering
the libgloss port was merged in 2009, ~14 years seems like plenty
of leeway. Which is to say, no one else can seem to build this
which makes updating & testing things very difficult.
Ignoring that, from what I can tell, this port has only ever built
and installed a crt0.o file. It defines libeval.a & libcygmon.a
targets, but nothing depends on them. The SCRIPTS & BSP variables
are always empty. The original port merge define these in the
configure script as substitutes, but never set the vars, so they
were always replaced with nothing.
I actually broke this build 2 years ago when merging the configure
up a level in commit 30f244155b
("libgloss: merge subdirs that have unique makefile_frags up a
level"). I saw that it was exporting a bunch of vars in the
configure script, but never set them, so I incorrectly assumed
they weren't used. Which means the Makefile has been setting them
to invalid values like literal @bsp_list@ and @script_list@.
Considering no one has complained, I have to assume no one cares
about this port, and we can all stop wasting time on it.
Fix a compile error due to duplicate pthreads types:
.../libgloss/sparc_leon/mutex.c:50:8: error: conflicting types for ‘pthread_mutex_t’; have ‘struct pthread_mutex’
50 | } pthread_mutex_t;
In file included from .../newlib/libc/include/sys/types.h:221,
from .../libgloss/sparc_leon/mutex.c:26:
.../newlib/libc/include/sys/_pthreadtypes.h:154:20: note: previous declaration of ‘pthread_mutex_t’ with type ‘pthread_mutex_t’ {aka ‘long unsigned int’}
154 | typedef __uint32_t pthread_mutex_t; /* identify a mutex */
.../libgloss/sparc_leon/mutex.c:57:8: error: conflicting types for ‘pthread_mutexattr_t’; have ‘struct <anonymous>’
57 | } pthread_mutexattr_t;
../newlib/libc/include/sys/_pthreadtypes.h:169:3: note: previous declaration of ‘pthread_mutexattr_t’ with type ‘pthread_mutexattr_t’
169 | } pthread_mutexattr_t;
Avoid a recursive make to speed things up a bit.
A ft32-elf build shows installed objects & libs produce same code.
Mention of ft32-elf-common.ld is dropped as it has never existed
in the tree, and has been an (ignored) error in the past.
This is a .c file, not assembly, and it's a duplicate (same content)
as the existing sim-lseek.c. Delete it since it's unused and doesn't
actually compile.
Avoid a recursive make to speed things up a bit.
A fr30-elf build shows installed objects & libs produce same code.
A lot of code seems like it hasn't been migrated, but that's because
it's all disabled/unused (i.e. all the test & mon code). It looks
like a lot of copy & paste holdovers from the original port.
No sub-Makefile.inc file should ever set CPPFLAGS directly. That is
a global/common variable. Instead, ports should set the per-target
CPPFLAGS to include what they need.
Further, per-target CPPFLAGS should respect $(AM_CPPFLAGS).
The code was loading the common ../sbrk.c file rather than the visium
specific sbrk.c due to VPATH setup. Add an explicit rule for this one
file so we make sure the correct one is used.
Alexey Lapshin
Yuriy Kolerov
Alexey Brodkin
Christophe Lyon
Yuriy Kolerov
Claudiu Zissulescu
Vladimir Isaev
Luis Silva
Dimitar Dimitrov
Neal Frager
Marc
Bernd Edlinger
Mike Frysinger