alpha
Login
or
Join now
theoparis.com
/
binutils-apple
Star
0
Fork
0
Atom
Configure Feed
Issues
Pull Requests
Commits
Tags
Feed URL
Select the types of activity you want to include in your feed.
WIP MachO binutils port assisted by AI I may consider upstreaming this in the future.
Star
0
Fork
0
Atom
Configure Feed
Issues
Pull Requests
Commits
Tags
Feed URL
Select the types of activity you want to include in your feed.
Overview
Issues
Pulls
Pipelines
binutils-apple
/
sim
/
testsuite
/
cris
/
c
/
at
master
136 files
Tom Tromey
Update copyright dates to include 2026
6mo ago
4abc1ce2
access1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
append1.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
badldso1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
badldso2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
badldso3.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
c.exp
Update copyright dates to include 2026 This updates the copyright headers to include 2026. I did this by running gdb/copyright.py and then manually modifying a few files as noted by the script.
6 months ago
clone1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
clone2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
clone3.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
clone4.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
clone5.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
clone6.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
ex1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
exitg1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
exitg2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
fcntl1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
fcntl2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
fdopen1.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
fdopen2.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
freopen1.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
freopen2.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
ftruncate1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
ftruncate2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
getcwd1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
gettod.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
hello.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
hellodyn.c
sim: testsuite: add support for $pwd replacements Extend the common test framework to support $pwd replacements in settings. This allows replacing the custom cris @exedir@ with it.
4 years ago
hellodyn2.c
sim: testsuite: add support for $pwd replacements Extend the common test framework to support $pwd replacements in settings. This allows replacing the custom cris @exedir@ with it.
4 years ago
hellodyn3.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
kill1.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
kill2.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
kill3.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
mapbrk.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
mmap1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
mmap2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
mmap3.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
mmap4.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
mmap5.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
mmap6.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
mmap7.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
mmap8.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
mprotect1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
mprotect2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
mremap.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
openpf1.c
sim/testsuite/cris: Remove faulty use of basename in C tests Calls to basename were added here as part of commit e1e1ae6e9b5e "sim: testsuite: fix objdir handling", but that commit missed adding "#include <libgen.h>" or the equivalent GNU extension, see basename(3). Fixing that shows a logical error in the change to openpf1.c; the non-/-prefixed code-path was changed instead of the "/"-prefixed code-path, which is the one executed after that commit. For "newlib" these tests failed linking after that commit. Recent newlib has the (asm-renamed) GNU-extension-variant of basename, but we're better off not using it at all. Unfortunately, compilation failures for C tests run by the machinery in c.exp are currently just marked "unresolved", in contrast to C and assembler tests run by calling run_sim_test. The interaction of calling with the full program-path vs. use of --sysroot exposes a consistency problem: when --sysroot is used, argv[0] isn't the path by which the program can find itself. It's undecided whether argv[0] for the program running in the simulator should be edited (related to the naked argument to the simulator before passing on to the simulated program) to remove a leading --sysroot. Either way, such a change would be out of scope for this commit. * c/stat3.c (mybasename): New macro. Use it instead of basename. * c/openpf1.c: Correct basename-related change and update related comment.
4 years ago
openpf2.c
sim: cris: replace @srcdir@ test extension with $srcdir/$subdir The common framework supports $srcdir & $subdir replacements already, so replace the custom @srcdir@ logic with those. Since the replace happens in slurp_options that cris already uses, we don't have any logic to port over there. We have to duplicate that into the cris slurp_rv helper though.
4 years ago
openpf3.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
openpf4.c
sim: testsuite: add support for $pwd replacements Extend the common test framework to support $pwd replacements in settings. This allows replacing the custom cris @exedir@ with it.
4 years ago
openpf5.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
pipe1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
pipe2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
pipe3.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
pipe4.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
pipe5.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
pipe6.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
pipe7.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
readlink1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
readlink10.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
readlink11.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
readlink2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
readlink3.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
readlink4.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
readlink5.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
readlink6.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
readlink7.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
readlink8.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
readlink9.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
rename2.c
sim: testsuite: fix objdir handling The tests assume that the cwd is the objdir directory and write its intermediates to there all the time. When using runtest's --objdir setting though, this puts the files in the wrong place. This isn't a big problem currently as we never change --objdir, but in order to support parallel test execution, we're going to start setting that option, so clean up the code ahead of time. We also have to tweak some of the cris tests which were making assumptions about the argv[0] value.
4 years ago
rtsigprocmask1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
rtsigprocmask2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
rtsigsuspend1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
rtsigsuspend2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sched1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sched2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sched3.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sched4.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sched5.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sched6.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sched7.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sched8.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sched9.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
seek1.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
seek2.c
sim: testsuite: add support for $pwd replacements Extend the common test framework to support $pwd replacements in settings. This allows replacing the custom cris @exedir@ with it.
4 years ago
seek3.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
seek4.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
setrlimit1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
settls1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sig1.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
sig10.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sig11.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sig12.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sig13.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sig2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sig3.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
sig4.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sig5.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
sig6.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sig7.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sig8.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
sig9.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sigreturn1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sigreturn2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sigreturn3.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sigreturn4.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sjlj.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
sock1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
stat1.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
stat2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
stat3.c
sim: testsuite: fix cris stat3 in diff setups This test uses the test itself as an input to stating regular files. This gets funky though: when we run check in parallel, the output object dir is the subdir that matches the .exp file. When we run with -j1, the output object dir is the sim builddir itself. The old test would append argv[0] to find the file, while the new test uses basename on it. Each method works in only one of the aforementioned build scenarios. Rather than complicate this any more, switch to a different file that we know will always exist: the Makefile.
3 years ago
stat4.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
stat5.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
stat7.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
stat8.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
syscall1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
syscall2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
syscall3.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
syscall4.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
syscall5.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
syscall6.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
syscall7.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
syscall8.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sysctl1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sysctl2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
sysctl3.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
thread2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
thread3.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
thread4.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
thread5.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
time1.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
time2.c
sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.
5 years ago
truncate1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
truncate2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
ugetrlimit1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
uname1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
writev1.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago
writev2.c
sim: testsuite: initial support for OS-specific tests We usually test against the newlib/libgloss environment, but for a few ports that also support Linux apps, we want to test that logic too. A lot of the C code is written such that it works with either newlib/libgloss or glibc/linux toolchains, but we have some tests that end up being Linux-specific. Cris has been using the target tuple as a rough proxy for this (where cris*-*-elf is assumed to be newlib/libgloss, and everything else is glibc/linux), but that is a bit too rough, and it doesn't work in a multitarget build. So lets create a few stub files that we can do compile tests with to detect the different setups, and then let tests declare which one they require (if they require any at all).
4 years ago