UCX: Add support for RISC-V #9168

rbradford · 2023-06-28T10:36:28Z

What

Adds support for compiling and running UCX on RISC-V (tested under RV64 QEMU.)

Why ?

Architecture specific code was missing for RISC-V (this adds that) and this
also addresses non RISC-V specific issues (although architecture dependent)
around the ELF symbol address and patching the PLT which are needed for correct
functioning.

How ?

Tested with UCX gtests and UCC gtests (patch required for UCC) on Linux under
RV64 QEMU.

UCS/ARCH/RV64: Add RISC-V support
UCM: Fix RELOC patching method for shared libraries
UCM/UTIL/RELOC: Don't rely on RTLD_NEXT for lookup

rbradford · 2023-07-03T16:13:03Z

@yosefe The PR is passing the CI and is ready for review. Please take a look when you can. Thanks!

yosefe · 2023-07-05T12:13:01Z

src/ucm/util/reloc.c

+    if (symtab < (void*)dl_info->start) {
+        symtab = (char*)symtab + dlpi_addr;
+    }


what is this doing?
maybe add a helper function to reduce code duplication?

My colleague @evangreen wrote this patch - he is the best person to respond. IIRC the issue is that the offsets can't just be used as pointers since on RISC-V the binary isn't loaded at 0 in the address space.

Right, parsing the headers to get the DT_* value doesn't necessarily get you the final VA of that entity if the library wasn't loaded at 0. So we sanity check to see "is this pointer at least beyond the lowest loaded address we found for this image?", and if not, we add the start to compensate for the offset the binary was actually loaded at. Basically a poor man's relocation.

but on other architectures the libraries are also not loaded at 0, and this code works.. is there some different with RISC-V here?
In any case, can use UCS_PTR_BYTE_OFFSET macro to add pointer to offset

Since this fix was to specifically address =reloc mode I would propose that this commit be dropped from this PR and I open another PR specifically about this incorporating some of the feedback and identifying the exact cause of the offset requirement (and why it isn't needed elsewhere.)

but on other architectures the libraries are also not loaded at 0, and this code works.. is there some different with RISC-V here? In any case, can use UCS_PTR_BYTE_OFFSET macro to add pointer to offset

@yosefe I was able to identify the root cause of the address vs offset situation which I documented in #9283 and addressed in #9284 taking in the feedback to use UCS_PTR_BYTE_OFFSET and consolidate where the addition of the base address needs to happen.

can we remove it from this PR then?

src/ucm/util/reloc.h

yosefe · 2023-07-05T12:17:24Z

src/ucm/util/reloc.h

+    dl = dlopen(info.dli_fname, flags);
+    if (dl != NULL) {
+        (void)dlerror();
+        func_ptr = dlsym(dl, symbol);


this changes the behavior: before the change the symbol was searched in the caller library (that could be libucm_cuda.so for example) and now it's always searched in libucm.so

The use of RTLD_NEXT seems to have caught other folks out in the past (https://optumsoft.com/dangers-of-using-dlsym-with-rtld_next/).

If I look at the order of the libraries in the ucc_gtest binary:

/ # /lib/ld-linux-riscv64-lp64d.so.1 --list bin/ucc_gtest linux-vdso.so.1 (0x00007fff8e757000) libucc.so.1 => /nix/store/37nj6mzi1n7lgdppk1zp51q07g1cvfi3-ucc-riscv64-unknown-linux-gnu-1.2.0-gdb5711b/lib/libucc.so.1 (0x00007fff8e726000) libucs.so.0 => /nix/store/07fvbv49gwvv24lls4nv1hb5zdizrcvd-ucx-riscv64-unknown-linux-gnu-1.16.0-g10c71f9/lib/libucs.so.0 (0x00007fff8e6c6000) librt.so.1 => /nix/store/wzxw87zd8195qpvr9qy1j4da2q2glcir-glibc-riscv64-unknown-linux-gnu-2.37-g4c09d4a/lib/librt.so.1 (0x00007fff8e6c3000) libstdc++.so.6 => /nix/store/021k38q6dk02cbhd2688853qaxbaf6pg-riscv64-unknown-linux-gnu-stage-final-gcc-debug-12.1.0-g043c545-lib/riscv64-unknown-linu x-gnu/lib/libstdc++.so.6 (0x00007fff8e4e7000) libm.so.6 => /nix/store/wzxw87zd8195qpvr9qy1j4da2q2glcir-glibc-riscv64-unknown-linux-gnu-2.37-g4c09d4a/lib/libm.so.6 (0x00007fff8e477000) libgcc_s.so.1 => /nix/store/021k38q6dk02cbhd2688853qaxbaf6pg-riscv64-unknown-linux-gnu-stage-final-gcc-debug-12.1.0-g043c545-lib/riscv64-unknown-linux -gnu/lib/libgcc_s.so.1 (0x00007fff8e463000) libpthread.so.0 => /nix/store/wzxw87zd8195qpvr9qy1j4da2q2glcir-glibc-riscv64-unknown-linux-gnu-2.37-g4c09d4a/lib/libpthread.so.0 (0x00007fff8e460000) libc.so.6 => /nix/store/wzxw87zd8195qpvr9qy1j4da2q2glcir-glibc-riscv64-unknown-linux-gnu-2.37-g4c09d4a/lib/libc.so.6 (0x00007fff8e32b000) /nix/store/wzxw87zd8195qpvr9qy1j4da2q2glcir-glibc-riscv64-unknown-linux-gnu-2.37-g4c09d4a/lib/ld-linux-riscv64-lp64d.so.1 => /lib/ld-linux-riscv64-lp6 4d.so.1 (0x00007fff8e759000) libucm.so.0 => /nix/store/07fvbv49gwvv24lls4nv1hb5zdizrcvd-ucx-riscv64-unknown-linux-gnu-1.16.0-g10c71f9/lib/libucm.so.0 (0x00007fff8e30f000) libbfd-2.40.0.20230213.so => /nix/store/crsgk85y7i6440xa1x331zzigvc34pbd-binutils-riscv64-unknown-linux-gnu-2.40.0-g3ac11f8-lib/lib/libbfd-2.40.0.2023 0213.so (0x00007fff8dd67000) libdl.so.2 => /nix/store/wzxw87zd8195qpvr9qy1j4da2q2glcir-glibc-riscv64-unknown-linux-gnu-2.37-g4c09d4a/lib/libdl.so.2 (0x00007fff8dd64000) libz.so.1 => /nix/store/r5mpd0cxlw2sj6a23gwwfs2assjsvzwf-zlib-riscv64-unknown-linux-gnu-1.2.13/lib/libz.so.1 (0x00007fff8dd4f000) libsframe.so.0 => /nix/store/crsgk85y7i6440xa1x331zzigvc34pbd-binutils-riscv64-unknown-linux-gnu-2.40.0-g3ac11f8-lib/lib/libsframe.so.0 (0x00007fff8dd 49000)

I can see that libucm comes after libc which means that RTLD_NEXT won't find it.

I was also worried about the affect of this change but all the tests on the CI pass with it - so I am fairly confident that this is the best solution (but open to alternatives!)

is it fixing a failure that happens with RISC-V? what was that change needed?
I'm worried it may break other use cases..

I understand - since this was specifically seen in with the UCC gtest (where RTLD_NEXT fell through to patching the PLT) i'm going to propose moving this to a separate PR/GitHub issue where we can discuss the behaviour (i'd also like to see if that fallthough to patching the PLT also occurs with the UCC gtest on x86-64.)

can we remove it from this PR then?

src/ucs/arch/rv64/bitops.h

src/ucs/arch/rv64/cpu.h

src/ucs/arch/rv64/global_opts.c

src/ucm/bistro/bistro_rv64.c

rbradford

@yosefe @tvegas1 Thank you for your responses. I've added additional patches to the PR to respond to your points (I understand you prefer patches only to be squashed when the review is concluded.)

src/ucs/arch/rv64/bitops.h

src/ucs/arch/rv64/cpu.h

src/ucs/arch/rv64/global_opts.c

src/ucm/util/reloc.h

rbradford · 2023-07-19T07:44:40Z

src/ucm/util/reloc.c

+    if (symtab < (void*)dl_info->start) {
+        symtab = (char*)symtab + dlpi_addr;
+    }


My colleague @evangreen wrote this patch - he is the best person to respond. IIRC the issue is that the offsets can't just be used as pointers since on RISC-V the binary isn't loaded at 0 in the address space.

src/ucm/bistro/bistro_rv64.c

rbradford · 2023-07-19T11:54:38Z

src/ucm/util/reloc.h

+    dl = dlopen(info.dli_fname, flags);
+    if (dl != NULL) {
+        (void)dlerror();
+        func_ptr = dlsym(dl, symbol);


The use of RTLD_NEXT seems to have caught other folks out in the past (https://optumsoft.com/dangers-of-using-dlsym-with-rtld_next/).

If I look at the order of the libraries in the ucc_gtest binary:

/ # /lib/ld-linux-riscv64-lp64d.so.1 --list bin/ucc_gtest linux-vdso.so.1 (0x00007fff8e757000) libucc.so.1 => /nix/store/37nj6mzi1n7lgdppk1zp51q07g1cvfi3-ucc-riscv64-unknown-linux-gnu-1.2.0-gdb5711b/lib/libucc.so.1 (0x00007fff8e726000) libucs.so.0 => /nix/store/07fvbv49gwvv24lls4nv1hb5zdizrcvd-ucx-riscv64-unknown-linux-gnu-1.16.0-g10c71f9/lib/libucs.so.0 (0x00007fff8e6c6000) librt.so.1 => /nix/store/wzxw87zd8195qpvr9qy1j4da2q2glcir-glibc-riscv64-unknown-linux-gnu-2.37-g4c09d4a/lib/librt.so.1 (0x00007fff8e6c3000) libstdc++.so.6 => /nix/store/021k38q6dk02cbhd2688853qaxbaf6pg-riscv64-unknown-linux-gnu-stage-final-gcc-debug-12.1.0-g043c545-lib/riscv64-unknown-linu x-gnu/lib/libstdc++.so.6 (0x00007fff8e4e7000) libm.so.6 => /nix/store/wzxw87zd8195qpvr9qy1j4da2q2glcir-glibc-riscv64-unknown-linux-gnu-2.37-g4c09d4a/lib/libm.so.6 (0x00007fff8e477000) libgcc_s.so.1 => /nix/store/021k38q6dk02cbhd2688853qaxbaf6pg-riscv64-unknown-linux-gnu-stage-final-gcc-debug-12.1.0-g043c545-lib/riscv64-unknown-linux -gnu/lib/libgcc_s.so.1 (0x00007fff8e463000) libpthread.so.0 => /nix/store/wzxw87zd8195qpvr9qy1j4da2q2glcir-glibc-riscv64-unknown-linux-gnu-2.37-g4c09d4a/lib/libpthread.so.0 (0x00007fff8e460000) libc.so.6 => /nix/store/wzxw87zd8195qpvr9qy1j4da2q2glcir-glibc-riscv64-unknown-linux-gnu-2.37-g4c09d4a/lib/libc.so.6 (0x00007fff8e32b000) /nix/store/wzxw87zd8195qpvr9qy1j4da2q2glcir-glibc-riscv64-unknown-linux-gnu-2.37-g4c09d4a/lib/ld-linux-riscv64-lp64d.so.1 => /lib/ld-linux-riscv64-lp6 4d.so.1 (0x00007fff8e759000) libucm.so.0 => /nix/store/07fvbv49gwvv24lls4nv1hb5zdizrcvd-ucx-riscv64-unknown-linux-gnu-1.16.0-g10c71f9/lib/libucm.so.0 (0x00007fff8e30f000) libbfd-2.40.0.20230213.so => /nix/store/crsgk85y7i6440xa1x331zzigvc34pbd-binutils-riscv64-unknown-linux-gnu-2.40.0-g3ac11f8-lib/lib/libbfd-2.40.0.2023 0213.so (0x00007fff8dd67000) libdl.so.2 => /nix/store/wzxw87zd8195qpvr9qy1j4da2q2glcir-glibc-riscv64-unknown-linux-gnu-2.37-g4c09d4a/lib/libdl.so.2 (0x00007fff8dd64000) libz.so.1 => /nix/store/r5mpd0cxlw2sj6a23gwwfs2assjsvzwf-zlib-riscv64-unknown-linux-gnu-1.2.13/lib/libz.so.1 (0x00007fff8dd4f000) libsframe.so.0 => /nix/store/crsgk85y7i6440xa1x331zzigvc34pbd-binutils-riscv64-unknown-linux-gnu-2.40.0-g3ac11f8-lib/lib/libsframe.so.0 (0x00007fff8dd 49000)

I can see that libucm comes after libc which means that RTLD_NEXT won't find it.

I was also worried about the affect of this change but all the tests on the CI pass with it - so I am fairly confident that this is the best solution (but open to alternatives!)

ct-clmsn · 2023-07-26T12:34:27Z

@rbradford please look at the prior PR for RISCV support. @yosefe thank you for bringing both efforts together!

#8246

rbradford · 2023-07-26T13:40:38Z

@rbradford please look at the prior PR for RISCV support. @yosefe thank you for bringing both efforts together!

#8246

Yes, this code is derived from that PR and fixed for coding style and bug fixes - I see you've updated it between when I created this PR and now - I thought your original PR was abandoned.

I would appreciate it if you would let me review the code before you finalise it as I think there might still be some minor issues.

rbradford · 2023-07-28T07:46:58Z

@yosefe I've updated this PR based on your feedback - the CI issues seem unrelated to the changes included in it.

ct-clmsn · 2023-07-28T18:01:13Z

@rbradford great work; UCX has changed a lot since #8246 was completed, so much so that I consider #8246 OBE (overcome by events).

@yosefe I'd encourage merging this PR and closing out #8246.

This PR has been successfully tested on a sifive unmatched and a pine64/star64 (starfive chip) sbc.

@rbradford I've made a PR on your branch for these files, feel free to ignore. The PR was supposed to update these files with compile guards around OpenMP pragmas; git decided to do add a bunch of other changes that weren't intended (maybe it was a sync against ucx-master/main).

./src/tools/perf/perftest.c
./src/tools/perf/lib/libperf.c
./test/apps/test_init_mt.c

ct-clmsn · 2023-07-28T18:08:54Z

@rbradford if possible, could you compare #8246's ucm_bistro_patch here between lines 80 and 92 against the version in this PR?

The implementation in this PR is using an older version of code from #8246 that has issues with address randomization. #8246 has been updated recently with a better version.

Thanks!

rbradford · 2023-07-31T16:29:35Z

@ct-clmsn Thank you for testing - I have integrated your OpenMP related patch. Also to avoid the sign extension problem I have switched to a different method for making the jump. By using AUIPC we can store the absolute 64-bit address in the instruction stream as a constant and then load it and jump to it. This avoids all sorts of issues with the sign extension of immediates. If you can - I would appreciate you giving it another test.

ct-clmsn · 2023-08-01T14:01:38Z

@rbradford will give it a test today. We made an effort to work with AUIPC awhile back - as you mentioned its the preferred approach. We ended up opting for JALR because we were getting some jump with no return program faults. In hindsight, that may have been associated with sign-extension issues in our address calculation. Expect a comment later today with an update!

ct-clmsn · 2023-08-01T15:47:49Z

@rbradford all is clear on this end; successfully completed several loopback tests on a star64 over ethernet.

yosefe · 2023-08-05T11:39:13Z

src/ucm/util/reloc.h

+    dl = dlopen(info.dli_fname, flags);
+    if (dl != NULL) {
+        (void)dlerror();
+        func_ptr = dlsym(dl, symbol);


is it fixing a failure that happens with RISC-V? what was that change needed?
I'm worried it may break other use cases..

src/ucs/arch/rv64/bitops.h

src/ucs/arch/rv64/global_opts.c

yosefe · 2023-08-05T11:43:32Z

src/ucm/util/reloc.c

+    if (symtab < (void*)dl_info->start) {
+        symtab = (char*)symtab + dlpi_addr;
+    }


but on other architectures the libraries are also not loaded at 0, and this code works.. is there some different with RISC-V here?
In any case, can use UCS_PTR_BYTE_OFFSET macro to add pointer to offset

src/ucs/arch/rv64/cpu.h

rbradford

Hi @yosefe - i'm proposing to drop the two parts of this PR that are not purely RISC-V enabling and put them in separate PRs for more focussed discussion.

src/ucs/arch/rv64/global_opts.c

src/ucs/arch/rv64/bitops.h

rbradford · 2023-08-07T15:26:20Z

src/ucm/util/reloc.h

+    dl = dlopen(info.dli_fname, flags);
+    if (dl != NULL) {
+        (void)dlerror();
+        func_ptr = dlsym(dl, symbol);


I understand - since this was specifically seen in with the UCC gtest (where RTLD_NEXT fell through to patching the PLT) i'm going to propose moving this to a separate PR/GitHub issue where we can discuss the behaviour (i'd also like to see if that fallthough to patching the PLT also occurs with the UCC gtest on x86-64.)

rbradford · 2023-08-07T15:27:58Z

src/ucm/util/reloc.c

+    if (symtab < (void*)dl_info->start) {
+        symtab = (char*)symtab + dlpi_addr;
+    }


Since this fix was to specifically address =reloc mode I would propose that this commit be dropped from this PR and I open another PR specifically about this incorporating some of the feedback and identifying the exact cause of the offset requirement (and why it isn't needed elsewhere.)

rbradford · 2023-08-07T15:31:02Z

Hi @yosefe - i'm proposing to drop the two parts of this PR that are not purely RISC-V enabling and put them in separate PRs for more focussed discussion.

I'd also squash the remaining RISC-V enabling commits into just one.

yosefe · 2023-08-07T15:47:34Z

@rbradford per https://github.com/openucx/ucx/wiki/Guidance-for-contributors, please do not force push code review changes since it's not possible to track the diff vs. the previous review round.
Please rebase the branch on the previously reviewed revision and force-push to fix it

rbradford · 2023-08-07T15:51:32Z

@rbradford per https://github.com/openucx/ucx/wiki/Guidance-for-contributors, please do not force push code review changes since it's not possible to track the diff vs. the previous review round. Please rebase the branch on the previously reviewed revision and force-push to fix it

Okay - I only did so to remove the already merged patch.

rbradford · 2023-08-07T15:55:36Z

@rbradford per https://github.com/openucx/ucx/wiki/Guidance-for-contributors, please do not force push code review changes since it's not possible to track the diff vs. the previous review round. Please rebase the branch on the previously reviewed revision and force-push to fix it

Done!

yosefe · 2023-08-13T14:08:37Z

@rbradford pls also note the merge conflict

rbradford · 2023-08-22T13:08:37Z

@rbradford pls also note the merge conflict

Apologies for the delay in response i've been away. @yosefe How would you like me to resolve this? Ordinarily I would rebase onto master since the problem comes from a conflict with a fix that has been landed into master, however you asked me not to rebase. Do you prefer a merge commit from master into this branch (I couldn't find anything in the UCX developer documentation about this.)

yosefe · 2023-08-22T14:39:26Z

@rbradford pls also note the merge conflict

Apologies for the delay in response i've been away. @yosefe How would you like me to resolve this? Ordinarily I would rebase onto master since the problem comes from a conflict with a fix that has been landed into master, however you asked me not to rebase. Do you prefer a merge commit from master into this branch (I couldn't find anything in the UCX developer documentation about this.)

@rbradford please push a merge commit, thanks!

rbradford · 2023-08-23T07:53:57Z

@rbradford pls also note the merge conflict

Apologies for the delay in response i've been away. @yosefe How would you like me to resolve this? Ordinarily I would rebase onto master since the problem comes from a conflict with a fix that has been landed into master, however you asked me not to rebase. Do you prefer a merge commit from master into this branch (I couldn't find anything in the UCX developer documentation about this.)

@rbradford please push a merge commit, thanks!

Done - I also took the patch from #9284 and adapted it remove the heuristic and instead make a pointer from the offset if built with RISC-V.

I know that the dlsym related change is controversial (but the CI runs through with it fine) so i'm happy to move that to a separate PR and issue to discuss as it's only required for running with UCC.

rbradford · 2023-08-23T07:57:39Z

@yosefe I had to force push since the commit title check doesn't like "Revert" commits (but it is happy with "Merge" ones)

src/ucm/util/reloc.c

yosefe

pls squash

This patch is the derived from the work done by Chris Taylor and John Leidel (from this PR: https://github.com/openucx/ucx/pull/8246/commits) The ways in which this patch differs from that PR are: * Use __clear_cache() for i-cache updates with correct syscall fallback (need to pass 0 for all CPUs) (myself) * Use appropriate fence instructions for IO and CPU fences (myself) * Coding standard fixes (myself) * Removal of unused rv64/atomic.h (myself) * Header guard fixes (myself) * Removal of unused UCS_CPU_MODEL_RV64IMAFDC (myself) * Use generic time functions (Evan Green) * Calculate ilog2 correctly using clz (myself) * Use AUIPC+JALR rather than immediate calculations for patch (myself) * Support for atomic bistro patching (myself) Original-author: Chris Taylor <ctaylor@tactcomplabs.com> Original-author: John Leidel <john.leidel@gmail.com> Co-authored-by: Evan Green <evan@rivosinc.com> Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Signed-off-by: Evan Green <evan@rivosinc.com>

Rather than relying on RTLD_NEXT to return the symbol and falling back to RTLD_DEFAULT instead lookup the symbol from the current shared library directly. This resolves an issue where on RISC-V in some circumstances the symbol returned by RTLD_NEXT is null and RTLD_DEFAULT then provides a pointer into the PLT stub. Since the PLT stub is too small to be patched by directly resolving the symbol here the PLT is avoided and the C library function can be directly patched. Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

On some combinations of C library implementation and architecture the entries in the PT_DYNAMIC table are not relocated and stored as pointers. Instead the values are offsets from the address that the library is loaded at. RISC-V with glibc is one such example. Unfortunately since the internal glibc headers that expose whether the value is relocated on not are not available the best solution is to make this architecturally conditional. As this behaviour is now established as part of the ABI it will not change in the future. Since this should only be done for the values from the table that are treated like pointers create a new function ucm_reloc_get_pointer() that applies the architecture check was added This issue was discovered when using UCX_MEM_MMAP_HOOK_MODE=reloc on RISC-V. Fixes: openucx#9283 Co-developed-by: Evan Green <evan@rivosinc.com> Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

rbradford · 2023-08-23T16:25:09Z

pls squash

Thanks! Consolidated into three logical commits - unfortunately it looks like there is some unrelated CI problems.

rbradford marked this pull request as ready for review June 28, 2023 10:37

rbradford force-pushed the 20230628-riscv-enabling branch 2 times, most recently from 00da96b to 3ac64f4 Compare June 29, 2023 21:39

rbradford marked this pull request as draft June 30, 2023 00:36

rbradford force-pushed the 20230628-riscv-enabling branch 2 times, most recently from e9833c9 to cac50b1 Compare June 30, 2023 10:32

rbradford marked this pull request as ready for review June 30, 2023 16:41

yosefe reviewed Jul 5, 2023

View reviewed changes

tvegas1 reviewed Jul 10, 2023

View reviewed changes

src/ucm/bistro/bistro_rv64.c Outdated Show resolved Hide resolved

rbradford force-pushed the 20230628-riscv-enabling branch from cac50b1 to 95202dd Compare July 19, 2023 12:04

rbradford commented Jul 19, 2023

View reviewed changes

rbradford force-pushed the 20230628-riscv-enabling branch from 61aac39 to 95202dd Compare July 20, 2023 16:56

rbradford mentioned this pull request Jul 26, 2023

UCX: Adding support for RISC-V architecture; RV64G #8246

Closed

rbradford force-pushed the 20230628-riscv-enabling branch 2 times, most recently from e662599 to 1af06d0 Compare July 27, 2023 16:25

rbradford force-pushed the 20230628-riscv-enabling branch 2 times, most recently from 2fdb7c8 to b17bcb7 Compare August 1, 2023 08:14

yosefe reviewed Aug 5, 2023

View reviewed changes

rbradford force-pushed the 20230628-riscv-enabling branch from b17bcb7 to 8628a4a Compare August 7, 2023 15:20

rbradford commented Aug 7, 2023

View reviewed changes

rbradford force-pushed the 20230628-riscv-enabling branch from 8628a4a to f60b36c Compare August 7, 2023 15:54

rbradford force-pushed the 20230628-riscv-enabling branch from af54648 to 84f7eb0 Compare August 23, 2023 07:56

yosefe reviewed Aug 23, 2023

View reviewed changes

src/ucm/util/reloc.c Outdated Show resolved Hide resolved

yosefe approved these changes Aug 23, 2023

View reviewed changes

rbradford and others added 3 commits August 23, 2023 12:10

rbradford force-pushed the 20230628-riscv-enabling branch from 64f6f4b to c8e9502 Compare August 23, 2023 11:29

rbradford mentioned this pull request Aug 23, 2023

UCM/UTIL/RELOC: Don't assume dynamic table values are pointers #9284

Closed

yosefe approved these changes Aug 24, 2023

View reviewed changes

yosefe enabled auto-merge August 24, 2023 07:09

yosefe merged commit 3cdccef into openucx:master Aug 24, 2023

bedroge mentioned this pull request Apr 26, 2024

add RISC-V support to UCX 1.15.0 easybuilders/easybuild-easyconfigs#20429

Merged

UCX: Add support for RISC-V #9168

UCX: Add support for RISC-V #9168

Uh oh!

Conversation

rbradford commented Jun 28, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What

Why ?

How ?

Uh oh!

rbradford commented Jul 3, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rbradford left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ct-clmsn commented Jul 26, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rbradford commented Jul 26, 2023

Uh oh!

rbradford commented Jul 28, 2023

Uh oh!

ct-clmsn commented Jul 28, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ct-clmsn commented Jul 28, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rbradford commented Jul 31, 2023

Uh oh!

ct-clmsn commented Aug 1, 2023

Uh oh!

ct-clmsn commented Aug 1, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

rbradford commented Jun 28, 2023 •

edited

Loading

ct-clmsn commented Jul 26, 2023 •

edited

Loading

ct-clmsn commented Jul 28, 2023 •

edited

Loading

ct-clmsn commented Jul 28, 2023 •

edited

Loading