Jump to page: 1 2
Thread overview
May 17
I have druntime working with the RISC-V backend (32-bit / Newlib based; I got backend errors for 64-bit; I can't test glibc in 32-bit because AFAIK there's no 32-bit RISC-V Linux).

It needed some workarounds due to the lack of proper atomics and TLS support in the backend, as well as Newlib limitations, but that's mostly taken care of. For Phobos to work properly the backend needs to support exceptions. Currently the backend seems to only emit code for the non-exceptional code path.

Does anyone here understand what an LLVM backend needs to do to get code generated for the exception stuff (e.g. landingpad, etc.)? I tried to look in the ARM backend but it wasn't very illuminating...
May 17
On Thursday, 17 May 2018 at 15:36:05 UTC, Luís Marques wrote:
> I have druntime working with the RISC-V backend (32-bit / Newlib based; I got backend errors for 64-bit; I can't test glibc in 32-bit because AFAIK there's no 32-bit RISC-V Linux).
>
> It needed some workarounds due to the lack of proper atomics and TLS support in the backend, as well as Newlib limitations, but that's mostly taken care of. For Phobos to work properly the backend needs to support exceptions. Currently the backend seems to only emit code for the non-exceptional code path.
>
> Does anyone here understand what an LLVM backend needs to do to get code generated for the exception stuff (e.g. landingpad, etc.)? I tried to look in the ARM backend but it wasn't very illuminating...

To clarify: the LLVM IR generated by LDC has the whole code, but the backend behaves as if an exception could never be thrown, and the exception handling stuff gets optimized away. Or so it seems, anyway.
May 17
On Thursday, 17 May 2018 at 15:36:05 UTC, Luís Marques wrote:
>
> Does anyone here understand what an LLVM backend needs to do to get code generated for the exception stuff (e.g. landingpad, etc.)? I tried to look in the ARM backend but it wasn't very illuminating...

Are you using LLVM trunk? RISC-V appears to be under active development:
http://www.lowrisc.org/blog/2017/09/moving-risc-v-llvm-forwards/
http://www.lowrisc.org/llvm/status/

More experts to answer your question are to be found on the llvm-dev mailinglist.

-Johan



May 17
On Thursday, 17 May 2018 at 17:45:24 UTC, Johan Engelen wrote:
> Are you using LLVM trunk? RISC-V appears to be under active development:
> http://www.lowrisc.org/blog/2017/09/moving-risc-v-llvm-forwards/
> http://www.lowrisc.org/llvm/status/

Yes and no. I used to use the lowRISC patches, since the trunk version used to be severely behind. But there were some bugs in the patched backend that were preventing further progress. With the latest merges the trunk now seems more usable (more complete, and the bugs exhibited by the patches seem to no longer be there) so I'm using that.

In any case, the author is the same (Alex Bradbury). I've been in contact with him, but he goes several months without replying, due to competing priorities and lack of funding.

I guess I could ask for help in the llvm-dev mailing list. I thought people here might be more motivated to help, given the focus on D support.
May 19
On Thursday, 17 May 2018 at 18:05:37 UTC, Luís Marques wrote:
> On Thursday, 17 May 2018 at 17:45:24 UTC, Johan Engelen wrote:
>> Are you using LLVM trunk? RISC-V appears to be under active development:
>> http://www.lowrisc.org/blog/2017/09/moving-risc-v-llvm-forwards/
>> http://www.lowrisc.org/llvm/status/
>
> Yes and no. I used to use the lowRISC patches, since the trunk version used to be severely behind. But there were some bugs in the patched backend that were preventing further progress. With the latest merges the trunk now seems more usable (more complete, and the bugs exhibited by the patches seem to no longer be there) so I'm using that.
>
> In any case, the author is the same (Alex Bradbury). I've been in contact with him, but he goes several months without replying, due to competing priorities and lack of funding.
>
> I guess I could ask for help in the llvm-dev mailing list. I thought people here might be more motivated to help, given the focus on D support.

I doubt any of us had to do much with exception-handling in a backend, it's just one of those features we get from llvm for free. Since we don't develop backends, you're better off asking the llvm guys, who do.
May 20
Hi Luís,

On 17 May 2018, at 16:36, Luís Marques via digitalmars-d-ldc wrote:
> Does anyone here understand what an LLVM backend needs to do to get code generated for the exception stuff (e.g. landingpad, etc.)? I tried to look in the ARM backend but it wasn't very illuminating...

I'm not sure there is a single answer to this question, as it is rather broad in scope.

First of all, what is the exception ABI for your target? Is it table-based using DWARF frame information? Or is it {set,long}jmp-based?

I don't quite remember whether this question has even been addressed for RISC-V so far, that is, whether there even is a compiler port that supports C++ exceptions, or an ABI document that prescribes a particular implementation. If there is none and you want to play around with an initial implementation of *something*, I'd probably choose the vanilla DWARF-based implementation as supported by libunwind.

From there, it's a matter of setting the ExceptionType correctly in your MCAsmInfo subclass, and fixing up various other bits and pieces as required. (For example, the code generator might need some tweaks to make sure the frame offset information is up to date, etc.) Grepping lib/Backend for `DwarfCFI` should provide you with some inspiration.

Best,
David
May 21
On Sunday, 20 May 2018 at 17:32:53 UTC, David Nadlinger wrote:
> First of all, what is the exception ABI for your target? Is it table-based using DWARF frame information? Or is it {set,long}jmp-based?

It's table-based DWARF.

> I don't quite remember whether this question has even been addressed for RISC-V so far, that is, whether there even is a compiler port that supports C++ exceptions, or an ABI document that prescribes a particular implementation.

Yeah, the GCC port of RISC-V includes exception support.

> From there, it's a matter of setting the ExceptionType correctly in your MCAsmInfo subclass, and fixing up various other bits and pieces as required. (For example, the code generator might need some tweaks to make sure the frame offset information is up to date, etc.) Grepping lib/Backend for `DwarfCFI` should provide you with some inspiration.

Cool, I'll look into that.
May 22
On Monday, 21 May 2018 at 13:48:36 UTC, Luís Marques wrote:
>> From there, it's a matter of setting the ExceptionType correctly in your MCAsmInfo subclass, and fixing up various other bits and pieces as required. (For example, the code generator might need some tweaks to make sure the frame offset information is up to date, etc.) Grepping lib/Backend for `DwarfCFI` should provide you with some inspiration.
>
> Cool, I'll look into that.

After setting the ExceptionType the exceptions weren't working correctly even with clang++. After diving into the details I found out that the use of .uleb128 in .gcc_except_table was preventing relocations of symbols referenced in that table from being generated. I changed  LLVM's backend configuration in MCObjectFileInfo.cpp to use the correct types and with clang++ exceptions now seem to be working, at least the minimal case I tested. LDC even after rebuilding is still using .uleb128 in .gcc_except_table, which is surprising, since it would seem that that configuration only depends on the chosen triple. So now I'm solving that part of the puzzle.
May 22
On Tuesday, 22 May 2018 at 12:42:47 UTC, Luís Marques wrote:
> After setting the ExceptionType the exceptions weren't working correctly even with clang++. After diving into the details I found out that the use of .uleb128 in .gcc_except_table was preventing relocations of symbols referenced in that table from being generated. I changed  LLVM's backend configuration in MCObjectFileInfo.cpp to use the correct types and with clang++ exceptions now seem to be working, at least the minimal case I tested. LDC even after rebuilding is still using .uleb128 in .gcc_except_table, which is surprising, since it would seem that that configuration only depends on the chosen triple. So now I'm solving that part of the puzzle.

I still haven't found it. Since this part is LDC specific and not LLVM specific, help here would be most appreciated :D
May 22
On Tuesday, 22 May 2018 at 14:31:17 UTC, Luís Marques wrote:
> I still haven't found it. Since this part is LDC specific and not LLVM specific, help here would be most appreciated :D

I think I mixed GCC code with clang++ code and came to the wrong conclusions.
But I found in LLVM where I actually have to change to emit the table with .4byte instead of .uleb128.
« First   ‹ Prev
1 2