GCC Copyright Assignment Forms for the RISC-V Port

[Palmer Dabbelt]

Andrew and I maintain various GNU toolchain forks that contains a port to the
RISC-V architecture .  We're finishing up the binutils
upstreaming process and would like to submit patches to GCC.  When I signed the
copyright assignment for binutils I was told that the GCC process was
different.  GCC's contributing page

  https://gcc.gnu.org/contribute.html

suggests I send email here to get the GCC copyright assignment forms.  Andrew
and I would both like to sign the forms for past and future changes, and SiFive
(Andrew's employer) will need the employer disclaimer if it's different than
the binutils one.

Thanks!

Re: RISC-V vector extension cauldron discussion

[Palmer Dabbelt]

Sorry if this is a bit roundabout, I wrote this over a few days and ended up 
thinking a bunch while writing.  As a result, the beginning might not match the 
end.


On Sat, 08 Sep 2018 03:04:38 PDT (-0700), r...@twiddle.net wrote:

This attempts to capture (most of) the two hour discussion that
we had in the Entrance Hall at GNU Cauldron yesterday.  Please
correct any faulty memory on my part and forward or cc this to
the appropriate RISC-V forum.


Thanks!

I think Roger forwarded this to the private RISC-V vector mailing list, but I'm 
not in the club so I'll have to talk about it here :)



The RISC-V vector extension described something other than what is
present in the currently released 2.2 standard.  To clarify the
language within this message, based on what I remember:


Yes.  The current RISC-V ISA standard contains no vector instructions, they 
will be added under the "V" extension as part of a future revision of the 
RISC-V standard.  This is how we manage the standard: as new revisions of the 
ISA manual come out we can add new extensions, but we can never change or 
remove an existing extension.



vl: the current number of elements that are active in each vector reg
maxvl:  the maximum number of elements in the current config
maxel:  the (maximum) element width within each vector reg
vsz:(new language here, vector size) maxvl * maxel

(I) We talked about the needs of the register allocator.

No one wants their loop kernel to spill registers, but eventually
it will happen, and we have to be prepared for it.

For a series of loop nests, while there is no spilling, it is easy
to select a vconfig for each loop nest independently.  However, when
spills occur, we need to be able to allocate spill slots of sufficient
size, and locate their position within the stack frame.

Because VECSZ can change based on vconfig, the only manageable frame
allocation strategy may require selecting a single vconfig for the
entire function.

We posited new instructions, vspill and vfill, that ignore VL, ignore
predication, and operate on all MAXVL elements of MAXEL.  This allows
the compiler to save and restore the entire contents of the register
without knowing the current configuration.


While I'm not part of the vector working group, I'd anticipate these sorts of 
instructions don't make it into the V extension because they leak too much 
about the microarchitecture to software.  One of the goals of the V extension 
is to allow for software compatibility between different implementations, and 
instructions with semantics like these tend to lead to incompatible software.


Additionally, I don't think this is necessary because our proposed vector ABI 
is to clobber the entire state of the vector unit on all function calls.  As a 
result, the compiler should always know how to spill registers: when you enter 
the function you don't have to spill anything, and if you spill as part of the 
loop you must have set up the vector unit in some manner and therefor should 
know about it.


This ABI may be a bad idea, but if we stick with it then we should be able to 
get away without this sort of instruction.  There's a few other places in the 
ISA where we've somewhat wed ourselves to this ABI, but with some modifications 
it might be possible to produce a reasonable one.


An instruction that does something similar (or even more revealing of the 
microarchitecture) may be necessary as part of the supervisor-mode vector 
extensions, but those are less scary because we can just mandate that 
supervisors write compatible code.  We operate under the assumption that we 
can't mandate anything about userspace.



We posited a new instruction, akin to SVE's addvl, such as

addvsz  rd, rs, imm (rd = rs + imm * vsz)

which can be used to rapidly size the stack frame and form addresses
of spill slots within the stack frame, also without knowing the current
configuration.  E.g.

addvsz  sp, fp, -7

to allocate space for 7 spill slots below the frame pointer.
When a spill needs to occur, use e.g.

addvsz  tmp, fp, -3
vspill  v0, tmp

In particular, this approach allows one to form the address in one
instruction instead of 3, and also providing VSZ implicitly as opposed
to requiring the register allocator to somehow re-materialize this value.

(Which is not impossible, given the example of pic_offset_register.
But also given that example, requires invasive special-casing within
the register allocator.  So, ew.)


I agree here: providing some mechanism to obtain the current VL should be 
provided by the ISA.  While it's not strictly necessary given the proposed ABI, 
it does avoid a bunch of headaches trying to ensure that value sticks around.  
I think it will end up being useful for any ABI that avoids clobbering every 
vector register.  I'd propose that the vector config should also be obtainable, 
which will also be useful for such an ABI.



(II) We talked about the needs of a "simd" abi

Re: RISC-V vector extension cauldron discussion

[Palmer Dabbelt]

On Tue, 11 Sep 2018 14:34:24 PDT (-0700), r...@twiddle.net wrote:

On 09/11/2018 09:28 AM, Palmer Dabbelt wrote:

The RISC-V vector extension described something other than what is
present in the currently released 2.2 standard.  To clarify the
language within this message, based on what I remember:


Yes.  The current RISC-V ISA standard contains no vector instructions, they
will be added under the "V" extension as part of a future revision of the
RISC-V standard.  This is how we manage the standard: as new revisions of the
ISA manual come out we can add new extensions, but we can never change or
remove an existing extension.


Well, right, but it does have a draft of the V extension.
What was presented did not match that, which is what I was trying to describe.


Ah, I didn't know that.  I guess I should look at our ISA manual more often... 
:)  Regardless, the presented extensions have drifted from v2.2 in various ways 
such that I'm no longer sure what is real any more.



We posited new instructions, vspill and vfill, that ignore VL, ignore
predication, and operate on all MAXVL elements of MAXEL.  This allows
the compiler to save and restore the entire contents of the register
without knowing the current configuration.


While I'm not part of the vector working group, I'd anticipate these sorts of
instructions don't make it into the V extension because they leak too much
about the microarchitecture to software.  One of the goals of the V extension
is to allow for software compatibility between different implementations, and
instructions with semantics like these tend to lead to incompatible software.


Pardon?  How do they leak micro-architecture detail?
They load and store the *architectural* contents of the registers.


Ya, I think I might have been wrong here.  When I actually went through this I 
think there might be a way to implement these with reasonable performance and 
without leaking any micro-architectural state.


My worry here was exactly how this whole "ignore VL" idea interplays with what 
values are allowed to exist in registers, which keeps flopping back and forth 
based on how much type support we're baking into the base ISA and who yells 
loudest in the meetings.  IIRC the current proposal is to have something like


  getvl t0 <- vl [imaginary instruction so we can restore vl]
  setvl 0
  vxor v0, v0
  setvl t0

be defined to change no V state, in which case I think it would be possible to 
define a sane version of these instructions.  I also think that a reasonable 
class of vector ABIs might rely on these, so we should probably figure out how 
to make them work.



Additionally, I don't think this is necessary because our proposed vector ABI
is to clobber the entire state of the vector unit on all function calls.


Yes, but I was foreshadowing...


(II) We talked about the needs of a "simd" abi


... this, in which we would not necessarily know the vconfig.


I think we start agreeing in a hundred lines or so... :)


Must is a strong word, but I agree that we should at least ensure that it's
possible to define a sane ABI that saves vector registers around function calls
and passes arguments via vector registers.  In other words: I think we'll still
want to support something like "-march=rv64gcv -mabi=lp64d", but I don't think
we want to preclude ourselves from "-march=rv64gcv -mabi=lp64dv" being better.

I think the best way to go about this is to figure out what features of an ABI
might be worth having, and then to enumerate the mechanisms that an V-style ISA
extension must provide in order to sanely implement such an ABI.  Essentially
we've still got time to change the ISA, so let's just design a good ABI, figure
out what's necessary from the ISA to implement said ABI, and then make sure
that's in the standard.


Sure.



The ABI features I can think of are:

* Passing at least one argument in a vector register.
   - Presumably we'll clobber vector argument registers on calls, like we do
 for everything else.  Thus there isn't any ISA requirement here.
   - How does one go about indicating at the C level that an argument is 
passed in a register?  If we just say "any __attribute__((vector)) of 
length less than N bytes/elements" then N must be less than the ISA 
mandated minimum vector length (IIRC 4 elements?) -- that might be OK.


Here I think you need to read the SVE document.


Yes, I agree that I should read the SVE document.  In fact, I opened it and 
scanned through it and though "gee, I should really read this".  By the time I 
got through the rest of your email the cauldron was almost over, and I figured 
I should send something.



I would not use this abi for __attribute__((vector(fixed-size))) at all, but
for the variable length vectors that the auto-vectorizer uses, since that's
exactly w

Re: Target maintainers: doc/install.texi love and care

[Palmer Dabbelt]

On Sun, 12 Mar 2017 04:27:26 PDT (-0700), ger...@pfeifer.com wrote:
> I noticed that the target-specific sections in doc/install.texi
> need a little lover and care.  It would be great could you have
> a look and streamline/update before the GCC 7 release.

I looked at our stuff (RISC-V) and there's almost nothing in there.  Is there
something I should add?  I looked at the aarch64 stuff in the "host/target
specific issues start here" section and there's some notes about binutils-2.24.
We'll require binutils-2.28 (the first version that we're upstream in), I can
add a note in that section about RISC-V as well if you think it's appropriate.

Re: Target maintainers: doc/install.texi love and care

[Palmer Dabbelt]

On Mon, 13 Mar 2017 01:59:28 PDT (-0700), ger...@pfeifer.com wrote:
> On Sun, 12 Mar 2017, Palmer Dabbelt wrote:
>> I looked at our stuff (RISC-V) and there's almost nothing in there.
>> Is there something I should add?  I looked at the aarch64 stuff in the
>> "host/target specific issues start here" section and there's some notes
>> about binutils-2.24. We'll require binutils-2.28 (the first version that
>> we're upstream in), I can add a note in that section about RISC-V as
>> well if you think it's appropriate.
>
> I am generally a fan of keeping documentation short (lest it is
> skipped or skimmed), but as long as necessary.
>
> In your case I don't think artificially blowing up the section on RISC-V
> to match others would be helpful.  However, given that binutils 2.28 is
> so brand new, that I'd definitely mention.
>
> (My proposals/patches yesterday are about removing references to ten
> year old versions of binutils from install.texi, quite the other end
> of the spectrum.)

Makes sense.  I think I found a few other problems in ours as well.  How does
this look?

[PATCH] RISC-V documentation cleanups

[PATCH] RISC-V documentation cleanups

[Palmer Dabbelt]

A recent mailing list post about install.texi cleanup suggested I take a
look at ours, and there were a few problems:

 * No table of contents entries
 * Not alphabetically ordered
 * Missing a note about requiring binutils-2.28

gcc/ChangeLog:

2017-03-13  Palmer Dabbelt  : Add table of contents
link.
: Likewise.
: Likewise
: Likewise.
: Re-arrange section
: Add a note about requiring binutils-2.28.
: Likewise.
: Likewise
: Likewise.
---
 gcc/ChangeLog| 13 +
 gcc/doc/install.texi | 30 +++---
 2 files changed, 36 insertions(+), 7 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index a4cd56f..9493330 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,16 @@
+2017-03-13  Palmer Dabbelt  : Add table of contents
+   link.
+   : Likewise.
+   : Likewise
+   : Likewise.
+   : Re-arrange section
+   : Add a note about requiring binutils-2.28.
+   : Likewise.
+   : Likewise
+   : Likewise.
+
 2017-03-13  Martin Liska  
 
PR middle-end/78339
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index dced17d..e7cb30c 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -3211,6 +3211,14 @@ information have to.
 @item
 @uref{#powerpcle-x-eabi,,powerpcle-*-eabi}
 @item
+@uref{#riscv32-x-elf,,riscv32-*-elf}
+@item
+@uref{#riscv32-x-linux,,riscv32-*-linux}
+@item
+@uref{#riscv64-x-elf,,riscv64-*-elf}
+@item
+@uref{#riscv64-x-linux,,riscv64-*-linux}
+@item
 @uref{#s390-x-linux,,s390-*-linux*}
 @item
 @uref{#s390x-x-linux,,s390x-*-linux*}
@@ -4288,21 +4296,27 @@ This configuration is intended for embedded systems.
 @heading riscv32-*-elf
 The RISC-V RV32 instruction set.
 This configuration is intended for embedded systems.
+This (and all other RISC-V) targets are supported upstream as of the
+binutils-2.28 release.
 
 @html
 
 @end html
-@anchor{riscv64-x-elf}
-@heading riscv64-*-elf
-The RISC-V RV64 instruction set.
-This configuration is intended for embedded systems.
+@anchor{riscv32-x-linux}
+@heading riscv32-*-linux
+The RISC-V RV32 instruction set running GNU/Linux.
+This (and all other RISC-V) targets are supported upstream as of the
+binutils-2.28 release.
 
 @html
 
 @end html
-@anchor{riscv32-x-linux}
-@heading riscv32-*-linux
-The RISC-V RV32 instruction set running GNU/Linux.
+@anchor{riscv64-x-elf}
+@heading riscv64-*-elf
+The RISC-V RV64 instruction set.
+This configuration is intended for embedded systems.
+This (and all other RISC-V) targets are supported upstream as of the
+binutils-2.28 release.
 
 @html
 
@@ -4310,6 +4324,8 @@ The RISC-V RV32 instruction set running GNU/Linux.
 @anchor{riscv64-x-linux}
 @heading riscv64-*-linux
 The RISC-V RV64 instruction set running GNU/Linux.
+This (and all other RISC-V) targets are supported upstream as of the
+binutils-2.28 release.
 
 @html
 
-- 
2.10.2

Backporting Patches to GCC 7

[Palmer Dabbelt]

I just submitted two patches against trunk.  I'd like to also have them on the
7 branch, so when 7.2 comes out we'll have them.  These patches only touch the
RISC-V backend, which I'm a maintainer of.  Is there a branch maintainer I'm
supposed to have sign off on the patches or am I meant to just decide on my own
what I should commit?

For reference, here's the patches

284b54c RISC-V: Add -mstrict-align option
70218e8 RISC-V: Unify indention in riscv.md

Re: Backporting Patches to GCC 7

[Palmer Dabbelt]

On Tue, 09 May 2017 01:50:42 PDT (-0700), richard.guent...@gmail.com wrote:
> On Mon, May 8, 2017 at 10:00 PM, Jonathan Wakely  
> wrote:
>> On 5 May 2017 at 21:35, Palmer Dabbelt wrote:
>>> I just submitted two patches against trunk.  I'd like to also have them on 
>>> the
>>> 7 branch, so when 7.2 comes out we'll have them.  These patches only touch 
>>> the
>>> RISC-V backend, which I'm a maintainer of.  Is there a branch maintainer I'm
>>> supposed to have sign off on the patches or am I meant to just decide on my 
>>> own
>>> what I should commit?
>>>
>>> For reference, here's the patches
>>>
>>> 284b54c RISC-V: Add -mstrict-align option
>>> 70218e8 RISC-V: Unify indention in riscv.md
>>
>> In general, backports that aren't fixing regressions or documentation
>> would need release managers approval. There's some leeway for target
>> maintainers of ports and other subsystems, for example I sometimes
>> make executive decisions about the C++ runtime libraries when the
>> backport only affects an isolated part of the library, or is clearly
>> safe and an obvious improvement. For bigger changes that aren't
>> regressions but I'd like to backport I still seek RM approval.
>>
>> I would guess that for RISC-V which is new in 7.1, if you think the
>> backport is important and it doesn't affect other targets then it
>> should be OK.
>>
>> Maybe one of the release managers can confirm that though.
>
> Generally all maintainers can also approve backports.

OK, thanks.  Since the RISC-V port is so new I'd like to be a bit aggressive
about backporting our fixes.  If this goes anything like binutils did, there's
going to be a handful of bug fixes that trickle in over the next few weeks as
more people start using the port now that there's a release.  For example,
we've got a few patches in the pipeline that get our -mcmodel=medany working
passing the test suite.

Is it OK if I pretty much just backport everything RISC-V related to
gcc-7-branch, as long as it doesn't touch any other port?  I can ping you about
each patch if you'd like.

Re: Backporting Patches to GCC 7

[Palmer Dabbelt]

On Wed, 10 May 2017 01:35:11 PDT (-0700), richard.guent...@gmail.com wrote:
> On Wed, May 10, 2017 at 2:31 AM, Palmer Dabbelt  wrote:
>> On Tue, 09 May 2017 01:50:42 PDT (-0700), richard.guent...@gmail.com wrote:
>>> On Mon, May 8, 2017 at 10:00 PM, Jonathan Wakely  
>>> wrote:
>>>> On 5 May 2017 at 21:35, Palmer Dabbelt wrote:
>>>>> I just submitted two patches against trunk.  I'd like to also have them 
>>>>> on the
>>>>> 7 branch, so when 7.2 comes out we'll have them.  These patches only 
>>>>> touch the
>>>>> RISC-V backend, which I'm a maintainer of.  Is there a branch maintainer 
>>>>> I'm
>>>>> supposed to have sign off on the patches or am I meant to just decide on 
>>>>> my own
>>>>> what I should commit?
>>>>>
>>>>> For reference, here's the patches
>>>>>
>>>>> 284b54c RISC-V: Add -mstrict-align option
>>>>> 70218e8 RISC-V: Unify indention in riscv.md
>>>>
>>>> In general, backports that aren't fixing regressions or documentation
>>>> would need release managers approval. There's some leeway for target
>>>> maintainers of ports and other subsystems, for example I sometimes
>>>> make executive decisions about the C++ runtime libraries when the
>>>> backport only affects an isolated part of the library, or is clearly
>>>> safe and an obvious improvement. For bigger changes that aren't
>>>> regressions but I'd like to backport I still seek RM approval.
>>>>
>>>> I would guess that for RISC-V which is new in 7.1, if you think the
>>>> backport is important and it doesn't affect other targets then it
>>>> should be OK.
>>>>
>>>> Maybe one of the release managers can confirm that though.
>>>
>>> Generally all maintainers can also approve backports.
>>
>> OK, thanks.  Since the RISC-V port is so new I'd like to be a bit aggressive
>> about backporting our fixes.  If this goes anything like binutils did, 
>> there's
>> going to be a handful of bug fixes that trickle in over the next few weeks as
>> more people start using the port now that there's a release.  For example,
>> we've got a few patches in the pipeline that get our -mcmodel=medany working
>> passing the test suite.
>>
>> Is it OK if I pretty much just backport everything RISC-V related to
>> gcc-7-branch, as long as it doesn't touch any other port?  I can ping you 
>> about
>> each patch if you'd like.
>
> Backporting patches that just affect RISC-V (aka in gcc/config/riscv/) is 
> fine.
> RISC-V is neither a primary nor secondary target so bugs (or failure to build)
> does not block doing releases from the branch so it's your responsibility to
> make sure the port stays healthy on the branch.

OK, thanks!

[PATCH] RISC-V: Add Jim Wilson as a maintainer

[Palmer Dabbelt]

Jim has recently started working at SiFive, where he'll be contributing
to our GCC port.  Andrew, Kito and I would like him to be a mainatiner.
My understand is that this is the right place to ask.

I've also changed my address to my SiFive one, where I also work -- it
seems cleaner to have everyone use our proper email address.

ChangeLog

2017-11-06  Palmer Dabbelt  

* MAINTAINERS (RISC-V): Add Jim Wilson as a maintainer.
Use my SiFive email address.
---
 MAINTAINERS | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9c3a56ea0941..26e8697079d4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -93,8 +93,9 @@ pdp11 portPaul Koning 
 picochip port  Daniel Towner   
 powerpcspe portAndrew Jenner   

 riscv port Kito Cheng  
-riscv port         Palmer Dabbelt  
+riscv port         Palmer Dabbelt  
 riscv port Andrew Waterman 
+riscv port Jim Wilson  
 rl78 port  DJ Delorie  
 rs6000/powerpc portDavid Edelsohn  
 rs6000/powerpc portSegher Boessenkool  
-- 
2.13.6

Re: [PATCH] RISC-V: Add Jim Wilson as a maintainer

[Palmer Dabbelt]

On Tue, 07 Nov 2017 05:02:13 PST (-0800), dje@gmail.com wrote:
> On Tue, Nov 7, 2017 at 2:14 AM, Jakub Jelinek  wrote:
>> On Mon, Nov 06, 2017 at 06:39:20PM -0800, Palmer Dabbelt wrote:
>>> Jim has recently started working at SiFive, where he'll be contributing
>>> to our GCC port.  Andrew, Kito and I would like him to be a mainatiner.
>>> My understand is that this is the right place to ask.
>>
>> It is the steering committee that appoints maintainers and so somebody
>> needs to suggest this to the steering committee, which Jim Wilson is
>> a member of.  Jim is a global reviewer, so even without being riscv
>> port maintainer he can review riscv patches other people wrote, just not his
>> own.
>>
>> So, I think for the time being you should just update your mail in
>> MAINTAINERS and let the SC decide on further maintainers.
>
> I will forward the nomination.

Thanks

Re: [patches] Re: [PATCH] RISC-V: Add Jim Wilson as a maintainer

[Palmer Dabbelt]

On Tue, 07 Nov 2017 09:47:37 PST (-0800), Jim Wilson wrote:
> On Mon, Nov 6, 2017 at 6:39 PM, Palmer Dabbelt  wrote:
>>
>> +riscv port Jim Wilson  
>>
>>
> It is jimw not jim for the email address.  Please fix.

Sorry.  We're still pending approval, but

diff --git a/MAINTAINERS b/MAINTAINERS
index 9c3a56ea0941..222dad81f2bb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -93,8 +93,9 @@ pdp11 portPaul Koning 
 picochip port  Daniel Towner   
 powerpcspe portAndrew Jenner   

 riscv port Kito Cheng      
-riscv port Palmer Dabbelt      
+riscv port Palmer Dabbelt  
 riscv port Andrew Waterman 
+riscv port Jim Wilson  
 rl78 port  DJ Delorie  
 rs6000/powerpc portDavid Edelsohn  
 rs6000/powerpc portSegher Boessenkool  

Re: [patches] Re: [PATCH] RISC-V: Add Jim Wilson as a maintainer

[Palmer Dabbelt]

On Tue, 07 Nov 2017 09:53:12 PST (-0800), Palmer Dabbelt wrote:

On Tue, 07 Nov 2017 09:47:37 PST (-0800), Jim Wilson wrote:

On Mon, Nov 6, 2017 at 6:39 PM, Palmer Dabbelt  wrote:


+riscv port Jim Wilson  



It is jimw not jim for the email address.  Please fix.


Sorry.  We're still pending approval, but

diff --git a/MAINTAINERS b/MAINTAINERS
index 9c3a56ea0941..222dad81f2bb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -93,8 +93,9 @@ pdp11 portPaul Koning 
 picochip port  Daniel Towner   
 powerpcspe portAndrew Jenner   

 riscv port Kito Cheng  
-riscv port Palmer Dabbelt  
+riscv port Palmer Dabbelt  
 riscv port Andrew Waterman 
+riscv port Jim Wilson  
 rl78 port  DJ Delorie  
 rs6000/powerpc portDavid Edelsohn  
 rs6000/powerpc portSegher Boessenkool  


Committed.

Re: RISC-V ELF multilibs

[Palmer Dabbelt]

On Tue, 29 May 2018 11:02:58 PDT (-0700), Jim Wilson wrote:

On 05/26/2018 06:04 AM, Sebastian Huber wrote:

Why is the default multilib and a variant identical?


This is supposed to be a single multilib, with two names.  We use
MULTILIB_REUSE to map the two names to a single multilib.

rohan:1030$ ./xgcc -B./ -march=rv64imafdc -mabi=lp64d --print-libgcc
./rv64imafdc/lp64d/libgcc.a
rohan:1031$ ./xgcc -B./ -march=rv64gc -mabi=lp64d --print-libgcc
./rv64imafdc/lp64d/libgcc.a
rohan:1032$ ./xgcc -B./ --print-libgcc
./libgcc.a
rohan:1033$

So this is working right when the -march option is given, but not when
no -march is given.  I'd suggest a bug report so I can track this, if
you haven't already filed one.


IIRC this is actually a limit of the GCC build system: there needs to be some 
default multilib, and it has to be unprefixed.  I wanted to keep the library 
paths orthogonal (ie, not bake in a default that rv64gc/lp64d lives at /lib), 
so I chose to just build a redundant multilib.


It'd be great to get rid of this, but I'm afraid it's way past my level of 
understanding as to how all this works.



Most variants include the C extension. Would it be possible to add -march=rv32g 
and -march=rv64g variants?


The expectation is that most implementations will include the C
extension.  It reduces code size, improves performance, and I think I
read somewhere that it takes only 400 gates to implement.

It isn't practical to try to support every possible combination of
architecture and ABI here, as there are too many possible combinations.
But if there is a major RISC-V target that is rv32g or rv64g then we
should consider it.  You can of course define your own set of multilibs.


While that's the standard answer, note that Sebastian added the RISC-V RTEMS 
target in the first place so as far as I'm concerned he can add additional 
multilibs to it if he wants.  While I'm not opposed to RTEMS multilibs for 
rv32g/ilp32d and rv64g/lp64d, note that we have made the decision in Linux land 
that the C extension will be common and thus I expect most RISC-V 
implementations with virtual memory to also have the C extension.  If you go 
down this route then you should move RTEMS to its own multilib target fragment 
(t-rtems-multilib or something similar).


If you need help figuring out the patch feel free to ask.  I wrote a blog that 
might be useful


   https://www.sifive.com/blog/2017/09/18/all-aboard-part-5-risc-v-multilib/

RE: RISC-V ELF multilibs

[Palmer Dabbelt]

On Thu, 31 May 2018 07:23:22 PDT (-0700), matthew.fort...@mips.com wrote:

Palmer Dabbelt  writes:

On Tue, 29 May 2018 11:02:58 PDT (-0700), Jim Wilson wrote:
> On 05/26/2018 06:04 AM, Sebastian Huber wrote:
>> Why is the default multilib and a variant identical?
>
> This is supposed to be a single multilib, with two names.  We use
> MULTILIB_REUSE to map the two names to a single multilib.
>
> rohan:1030$ ./xgcc -B./ -march=rv64imafdc -mabi=lp64d --print-libgcc
> ./rv64imafdc/lp64d/libgcc.a
> rohan:1031$ ./xgcc -B./ -march=rv64gc -mabi=lp64d --print-libgcc
> ./rv64imafdc/lp64d/libgcc.a
> rohan:1032$ ./xgcc -B./ --print-libgcc
> ./libgcc.a
> rohan:1033$
>
> So this is working right when the -march option is given, but not
when
> no -march is given.  I'd suggest a bug report so I can track this, if
> you haven't already filed one.

IIRC this is actually a limit of the GCC build system: there needs to
be some
default multilib, and it has to be unprefixed.  I wanted to keep the
library
paths orthogonal (ie, not bake in a default that rv64gc/lp64d lives at
/lib),
so I chose to just build a redundant multilib.

It'd be great to get rid of this, but I'm afraid it's way past my level
of
understanding as to how all this works.


I do actually have a solution for this but it is not submitted upstream.
MIPS has basically the same set of problems that RISC-V does in this area
and in an ideal world there would be no 'fallback' multilib such that if
you use compiler options that map to a library variant that does not
exist then the linker just fails to find any libraries at all rather than
using the default multilib.

I can share the raw patch for this and try to give you some idea about how
it works. I am struggling to find time to do much open source support at
the moment so may not be able to do all the due diligence to get it
committed. Would you be willing to take a look and do some of the work to
get it in tree?


If you have a rough patch that'd be great, it'll be at least a starting point.  
Last time I poked around I wasn't ever sure where to look.


Thanks!

Re: [RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (Jan 13, 2022)

[Palmer Dabbelt]

On Wed, 12 Jan 2022 05:48:41 PST (-0800), jia...@iscas.ac.cn wrote:

Hi all,

There is an agenda for tomorrow's meeting. If you have topics to
discuss or share, please let me know and I can add them to the agenda.


We should also talk about the ABI spec, we've now got a handful of 
incompatibilites between it and the binaries we currently 
generate/accept.




Agenda:
-  -misa-spec related issue:
- Bump default ISA spec to newer version, current default ISA spec
is 2.2, but it's already out-of-date for a long time
- The most impact is I ext. will bump to  2.1, which is
backward incompatible with 2.0,  I 2.1 has split csr instruction to
zicsr ext. and ifence.i  to zifencei ext., that might break some
existing build script.
- Discuss new scheme for -misa-spec or alternative scheme for
dealing with RISC-V profile

-  Interaction between -march and RISC-V profile[1].
- Introduce -mprofile option: -mprofile=rvm20 + -march=rv32gc
- Or extend syntax of -march option like -march=rvm20+mafdc?








-  RISC-V subextension  related implement progress

[1] Note: What is RISC-V Profile: https://github.com/riscv/riscv-profiles/

Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting.

Topic: RISC-V GNU Toolchain Biweekly Sync-up

Join Zoom Meeting
https://zoom.com.cn/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09

Meeting ID: 893 9360 0951
Passcode: 899662

BEIJING, China
11:00pThu, Jan 13 2022
12:00aFri, Jan 13 2022

PST/PDT, Pacific Standard Time (US)
7:00aThu, Jan 13 2022
8:00aThu, Jan 13 2022

PHILADELPHIA, United States, Pennsylvania
10:00aThu, Jan 13 2022
11:00aThu, Jan 13 2022

Re: [RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (Aripl 07, 2022)

[Palmer Dabbelt]

On Thu, Apr 7, 2022 at 4:16 AM jiawei  wrote:

> Yes, you are all right, now we are developing this under a temporary
> stable dev-spec. There may a lot of changes go to it's forzen version.
> Thanks for your remind anyway!
>
> Regards,
> PLCT Jiawei
>
>
>
> *ISCAS*
> 在 Philipp Tomsich ，2022年4月7日 下午5:20写道：
>
> Please note that the Zc* extension family did not make it to ratification
> last year.
> To my knowledge, the specification contents are not frozen and still
> subject to change.
>
> Thanks,
> Philipp.
>
> On Wed, 6 Apr 2022 at 14:11,  wrote:
>
>> Hi all,
>>
>> Here is the agenda for tomorrow's meeting. If you have topics to
>> discuss or share, please let me know and I can add them to the agenda.
>>
>> Agenda:
>>
>>
>> - "-latomic" and "-pthread" problem discuss in RISC-V [1]
>>
>>
>> -  RVV gcc implement progress [2]
>>
>>
>> -  RISC-V subextension  related implement progress
>>
>> - Zc* extension supports status
>>
>> - CMO extension supports status
>>
>> - ZTSO supports status
>>
>>
>> -  Open topics
>>
>>
>> [1] https://github.com/riscv-collab/riscv-gcc/issues/337
>>
>> [2] https://github.com/riscv-collab/riscv-gcc/tree/riscv-gcc-rvv-next
>>
>>https://github.com/riscv-collab/riscv-gcc/issues/335
>>
>>
>>
>> Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting.
>>
>>
>> Topic: RISC-V GNU Toolchain Biweekly Sync-up
>> Time: Mar 10, 2022 11:00 PM Singapore
>> Every 2 weeks on Thu, until Jun 30, 2022, 9 occurrence(s)
>>
>>
>> Please download and import the following iCalendar (.ics) files to your
>> calendar system.
>>
>> Weekly:
>>
>>
>> https://zoom.us/meeting/tZ0ufuqurjsjH9XTthkNg3MffX-QsRBuVBET/ics?icsToken=98tyKuGhrTIpHNSVuRyGRpx5A4r4b-7ziGJEgvplqAvtCA5UMS7wMNoPA6FNMs3m
>>
>>
>> Join Zoom Meeting
>> https://zoom.us/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09
>>
>>
>> Meeting ID: 893 9360 0951
>> Passcode: 899662
>>
>>
>> BEIJING, China
>> 10:00pThu, Aripl 07 2022
>>
>> 11:00aFri, Aripl 07 2022
>>
>> PST/PDT, Pacific Standard Time (US)
>> 7:00aThu, Aripl 07 2022
>> 8:00aThu, Aripl 07 2022
>
>
I'm even more confused than normal here: I attempted to show up at 7am, as
that's what my calendar said, ony to find that I couldn't get into Zoom and
see a message from Eric saying the calendar here links to 8am but that the
meeting was 7am.  Then I saw Jim and Kito reply to my "sorry, Zoom is
broken" message at 8am, saying the meeting was at 8am, so I went and had a
meeting.  After the meeting I talked to some folks who were in the 7am
meeting, which evidently happened as well.

Can we maybe get an auto-updated calendar for this meeting?


>
>>
>> PHILADELPHIA, United States, Pennsylvania
>> 10:00aThu, Aripl 07 2022
>> 11:00aThu, Aripl 07 2022
>>
>>
>> Paris, France
>> 16:00pThu, Aripl 07 2022
>> 17:00pThu, Aripl 07 2022
>>
>

RISC-V GCC Patchwork Sync-Up Meeting

[Palmer Dabbelt]

The topic of having some sort of RISC-V development meeting has come up 
a handful of times, but we never got around to actually setting anything 
up.  We've had a patchwork sync meeting for the RISC-V Linux port for a 
few months now and it's been super helpful, I figured it be best to just 
do something similar for GCC.


The idea is sort of copied from the glibc patchwork meeting, but I've 
never been to that before so it's a bit freeform.  Essentially we just 
run through the patch backlog and try to make sure everything has been 
triaged, which can go a lot quicker in real-time.  We also generally 
have time after the triaging to go through and talk about anything 
that's of interest.  Like the other meetings this is very much optional 
-- in other words, we'll still reflect anything discussed onto the 
mailing lists, this is just an additional place to talk.


Here's the Google Meet invite link:

   RISC-V GCC Patchwork Sync
   Tuesday, April 18 · 7:30 – 8:30am
   Google Meet joining info
   Video call link: https://meet.google.com/gsf-dchk-ijn

Happy to move to some other service if that's better for folks, this is 
just easy to set up on my end.  We can also move to another time if 
that's better for folks.  We'll start with every week at 7:30am Pacific.  
I've also got a calendar with just this meeting on it, in case it's 
easier to have that imported.


https://calendar.google.com/calendar/u/0?cid=Y18xZGUzNDJiN2I4ZmNhNWY4ODg3MWY5NmNkMTkzYmJmOTJkMDNiNmY0NDdlMzk5ZjFlNzA1ZWJjM2Y3Nzg5YTlkQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20

Sorry for the late notice, but I'd forgotten to actually send out an 
email.

GCC-13 Branch with RISC-V Performance-Related Backports

[Palmer Dabbelt]

Based on some discussions, it looks like a handful of vendors are 
planning on maintaining GCC-13 branches that include various 
performance-related backports (ie, patches not suitable for the standard 
GCC-13 release branch).


I don't think we'd actually agreed to a set of branch rules, but it 
seems like the following were where the discussion ended up:


* Make a "riscv" vendor branch.  I don't think we came up with a name, 
 but "riscv/gcc-13-perf" seems fine to me.

* Regularly rebase the branch on the GCC-13 release branch.
* Only accept backports that have landed on trunk.

There's a few others that I'd like to add, just based on poking around:

* No new regressions for anything that's backported.
* Use "git cherry-pick -x" from the trunk commit.

We're starting to land some gcc-14 patches already, so I'd prefer to 
make the branch sooner rather than later.  Unless there's any 
objections, I'll push what's at 
github.com/palmer-dabbelt/gcc/gcc-13-perf as a vendor branch.

Re: RISC-V GCC Patchwork Sync-Up Meeting

[Palmer Dabbelt]

On Mon, 17 Apr 2023 08:08:42 PDT (-0700), Palmer Dabbelt wrote:

The topic of having some sort of RISC-V development meeting has come up
a handful of times, but we never got around to actually setting anything
up.  We've had a patchwork sync meeting for the RISC-V Linux port for a
few months now and it's been super helpful, I figured it be best to just
do something similar for GCC.

The idea is sort of copied from the glibc patchwork meeting, but I've
never been to that before so it's a bit freeform.  Essentially we just
run through the patch backlog and try to make sure everything has been
triaged, which can go a lot quicker in real-time.  We also generally
have time after the triaging to go through and talk about anything
that's of interest.  Like the other meetings this is very much optional
-- in other words, we'll still reflect anything discussed onto the
mailing lists, this is just an additional place to talk.

Here's the Google Meet invite link:

RISC-V GCC Patchwork Sync
Tuesday, April 18 · 7:30 – 8:30am
Google Meet joining info
Video call link: https://meet.google.com/gsf-dchk-ijn

Happy to move to some other service if that's better for folks, this is
just easy to set up on my end.  We can also move to another time if
that's better for folks.  We'll start with every week at 7:30am Pacific.
I've also got a calendar with just this meeting on it, in case it's
easier to have that imported.

https://calendar.google.com/calendar/u/0?cid=Y18xZGUzNDJiN2I4ZmNhNWY4ODg3MWY5NmNkMTkzYmJmOTJkMDNiNmY0NDdlMzk5ZjFlNzA1ZWJjM2Y3Nzg5YTlkQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20

Sorry for the late notice, but I'd forgotten to actually send out an
email.


A handful of us met today and we decided a few things:

We're going to use the sourceware GCC patchwork.  That's shared between 
all GCC targets and there's a lot of outstanding patches for other 
ports, so we're just going to look at patches with "risc-v" in the 
subject (specifically 
<https://patchwork.sourceware.org/project/gcc/list/?q=risc-v>).  That 
doesn't mean we're going to stop looking at anything else, just that 
we're going to make sure all those patches get triaged regularly.


To make things manageable, we're going to just bulk archive everything 
from 2022 and earlier.  If there's anything in there folks want looked 
it then please ping it, but the assumption is that everything is 
sufficiently out of date that it at least needs to be rebased.


If that's OK with folks then I'll go archive the old RISC-V patches so 
we can get things triaged more easily.

Re: GCC-13 Branch with RISC-V Performance-Related Backports

[Palmer Dabbelt]

On Tue, 18 Apr 2023 06:19:07 PDT (-0700), jeffreya...@gmail.com wrote:



On 4/18/23 04:34, Kito Cheng wrote:

Based on some discussions, it looks like a handful of vendors are
planning on maintaining GCC-13 branches that include various
performance-related backports (ie, patches not suitable for the standard
GCC-13 release branch).


Did you consider also include necessary vectorizeor stuffs? I expect there would
be some patch in middle end for enable auto vec, like this:

https://patchwork.ozlabs.org/project/gcc/patch/20230407014741.139387-1-juzhe.zh...@rivai.ai/

I think to some degree middle end patches are inevitable.  I think the
same basic guidelines applies.  If it's on the trunk, then pulling it
over to our branch is implicitly OK.


Yep: I'd actually argue that middle-end patches are the reason we need a 
branch.  We're already somewhat libaral about backporting RISC-V backend 
patches, but there's going to be more substantial middle-end changes.



I don't think we'd actually agreed to a set of branch rules, but it
seems like the following were where the discussion ended up:

* Make a "riscv" vendor branch.  I don't think we came up with a name,
   but "riscv/gcc-13-perf" seems fine to me.
* Regularly rebase the branch on the GCC-13 release branch.


I would prefer merge rather than rebase since let us have a stable
sha1 as some reference point.

I slightly prefer the rebase approach.  Its easier to see where we are
relative to the current gcc-13 bits.  Doing an occasional forced update
isn't that bad (I've worked with this kind of flow for shared topic
branches in the past).  But if you feel strongly, I can live with a
merge flow as well.


I also think rebasing is slightly better, but not strongly.

Re: GCC-13 Branch with RISC-V Performance-Related Backports

[Palmer Dabbelt]

We talked about this a bit on IRC, but just to reflect it to the mailing 
lists:


On Tue, 18 Apr 2023 05:34:11 PDT (-0700), s...@gentoo.org wrote:


Palmer Dabbelt  writes:


Based on some discussions, it looks like a handful of vendors are
planning on maintaining GCC-13 branches that include various
performance-related backports (ie, patches not suitable for the
standard GCC-13 release branch).

I don't think we'd actually agreed to a set of branch rules, but it
seems like the following were where the discussion ended up:

* Make a "riscv" vendor branch.  I don't think we came up with a name,
  but "riscv/gcc-13-perf" seems fine to me.
* Regularly rebase the branch on the GCC-13 release branch.
* Only accept backports that have landed on trunk.


I'm a bit concerned about how distributions are supposed to handle this.

I can see riscv enthusiasts asking us to package the vendor branch -
which presumably won't get automatic snapshots created, so that's a bit
more manual work already. But supposing we switched to it entirely for
riscv, that might be ok. But what if there's also users who want the
conservative setup?

This feels (not to be a downer, sorry!) like a mess in the making
from the distribution perspective.


No problem, that's why we have these sorts of threads.


I've got to ask: given riscv isn't yet (as far as I understand), a
"premier platform" in GCC terms, couldn't you just be more liberal
with backports for riscv at least up until 13.2, or similar?


We've been pretty liberal about backports, but there's always some stuff 
that's just too much to for the standard branch.  It's looking like 14 
is shaping up to be a big one because of all the vector work going on, a 
lot of which is likely to touch core GCC code.



This is also a lot of work for a platform I don't even have access to
(we have Gentoo developers with riscv hardware, but not sure any of
it is powerful enough to be regularly testing this in addition to
the regular branch for riscv). If even a handful of other arches started
doing this, I would be completely overwhelmed with work.

Would this also be a long-term thing or just for 13?


We've essentailly done this for every release, it's just been at the 
RISC-V github.  Ideally we'll stop needing to be special, but given the 
history that might take a while.  The difference here is that we're 
trying to keep this at sourceware intsead of the RISC-V github, but 
that's really just because we've had so many headaches with RVI.


As to whether or not distros ship it: I've always been against distros 
shipping the RISC-V branches, as they're full of stuff that's not 
suitable for normal GCC releases and those policies are in place for a 
reason.  I know there's some vendors who ship them, but that's mostly in 
the embedded space and folks tend to have out of tree patches anyway so 
no big deal.


I treat these as more of a performance preview of the next GCC release, 
a handful of vendors were maintaining those internally.  I'd love if we 
could just use trunk for that, but it's generally not viable because too 
much stuff fails to build.



There's a few others that I'd like to add, just based on poking around:

* No new regressions for anything that's backported.
* Use "git cherry-pick -x" from the trunk commit.

We're starting to land some gcc-14 patches already, so I'd prefer to
make the branch sooner rather than later.  Unless there's any
objections, I'll push what's at
github.com/palmer-dabbelt/gcc/gcc-13-perf as a vendor branch.


thanks,
sam

Re: RISC-V GCC Patchwork Sync-Up Meeting

[Palmer Dabbelt]

On Tue, 18 Apr 2023 08:34:34 PDT (-0700), Palmer Dabbelt wrote:

On Mon, 17 Apr 2023 08:08:42 PDT (-0700), Palmer Dabbelt wrote:

The topic of having some sort of RISC-V development meeting has come up
a handful of times, but we never got around to actually setting anything
up.  We've had a patchwork sync meeting for the RISC-V Linux port for a
few months now and it's been super helpful, I figured it be best to just
do something similar for GCC.

The idea is sort of copied from the glibc patchwork meeting, but I've
never been to that before so it's a bit freeform.  Essentially we just
run through the patch backlog and try to make sure everything has been
triaged, which can go a lot quicker in real-time.  We also generally
have time after the triaging to go through and talk about anything
that's of interest.  Like the other meetings this is very much optional
-- in other words, we'll still reflect anything discussed onto the
mailing lists, this is just an additional place to talk.

Here's the Google Meet invite link:

RISC-V GCC Patchwork Sync
Tuesday, April 18 · 7:30 – 8:30am
Google Meet joining info
Video call link: https://meet.google.com/gsf-dchk-ijn

Happy to move to some other service if that's better for folks, this is
just easy to set up on my end.  We can also move to another time if
that's better for folks.  We'll start with every week at 7:30am Pacific.
I've also got a calendar with just this meeting on it, in case it's
easier to have that imported.

https://calendar.google.com/calendar/u/0?cid=Y18xZGUzNDJiN2I4ZmNhNWY4ODg3MWY5NmNkMTkzYmJmOTJkMDNiNmY0NDdlMzk5ZjFlNzA1ZWJjM2Y3Nzg5YTlkQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20

Sorry for the late notice, but I'd forgotten to actually send out an
email.


A handful of us met today and we decided a few things:

We're going to use the sourceware GCC patchwork.  That's shared between
all GCC targets and there's a lot of outstanding patches for other
ports, so we're just going to look at patches with "risc-v" in the
subject (specifically
<https://patchwork.sourceware.org/project/gcc/list/?q=risc-v>).  That
doesn't mean we're going to stop looking at anything else, just that
we're going to make sure all those patches get triaged regularly.

To make things manageable, we're going to just bulk archive everything
from 2022 and earlier.  If there's anything in there folks want looked
it then please ping it, but the assumption is that everything is
sufficiently out of date that it at least needs to be rebased.

If that's OK with folks then I'll go archive the old RISC-V patches so
we can get things triaged more easily.


After running a few of these, it turns out Meet has a few headaches so 
we're switching to Zoom.  I've updated the calendar, here's the Zoom 
meeting invite:


Palmer Dabbelt is inviting you to a scheduled Zoom meeting.

Topic: RISC-V GCC Pathwork Sync
Time: May 30, 2023 07:30 AM Pacific Time (US and Canada)
   Every week on Tue, until Jul 9, 2024, 59 occurrence(s)
   May 30, 2023 07:30 AM
   Jun 6, 2023 07:30 AM
   Jun 13, 2023 07:30 AM
   Jun 20, 2023 07:30 AM
   Jun 27, 2023 07:30 AM
   Jul 4, 2023 07:30 AM
   Jul 11, 2023 07:30 AM
   Jul 18, 2023 07:30 AM
   Jul 25, 2023 07:30 AM
   Aug 1, 2023 07:30 AM
   Aug 8, 2023 07:30 AM
   Aug 15, 2023 07:30 AM
   Aug 22, 2023 07:30 AM
   Aug 29, 2023 07:30 AM
   Sep 5, 2023 07:30 AM
   Sep 12, 2023 07:30 AM
   Sep 19, 2023 07:30 AM
   Sep 26, 2023 07:30 AM
   Oct 3, 2023 07:30 AM
   Oct 10, 2023 07:30 AM
   Oct 17, 2023 07:30 AM
   Oct 24, 2023 07:30 AM
   Oct 31, 2023 07:30 AM
   Nov 7, 2023 07:30 AM
   Nov 14, 2023 07:30 AM
   Nov 21, 2023 07:30 AM
   Nov 28, 2023 07:30 AM
   Dec 5, 2023 07:30 AM
   Dec 12, 2023 07:30 AM
   Dec 19, 2023 07:30 AM
   Dec 26, 2023 07:30 AM
   Jan 2, 2024 07:30 AM
   Jan 9, 2024 07:30 AM
   Jan 16, 2024 07:30 AM
   Jan 23, 2024 07:30 AM
   Jan 30, 2024 07:30 AM
   Feb 6, 2024 07:30 AM
   Feb 13, 2024 07:30 AM
   Feb 20, 2024 07:30 AM
   Feb 27, 2024 07:30 AM
   Mar 5, 2024 07:30 AM
   Mar 12, 2024 07:30 AM
   Mar 19, 2024 07:30 AM
   Mar 26, 2024 07:30 AM
   Apr 2, 2024 07:30 AM
   Apr 9, 2024 07:30 AM
   Apr 16, 2024 07:30 AM
   Apr 23, 2024 07:30 AM
   Apr 30, 2024 07:30 AM
   May 7, 2024 07:30 AM
   May 14, 2024 07:30 AM
   May 21, 2024 07:30 AM
   May 28, 2024 07:30 AM
   Jun 4, 2024 07:30 AM
   Jun 11, 2024 07:30 AM
   Jun 18, 2024 07:30 AM
   Jun 25, 2024 07:30 AM
   Jul 2, 2024 07:30 AM
   Jul 9, 2024 07:30 AM
Please download and import the following iCalendar (.ics) files to your 
calendar system.
Weekly: 
https://us02web.zoom.us/meeting/tZ0vc-GuqTMuHtVmPgBBAsUx

Re: [RFC] RISC-V: Go PLT for CALL/JUMP/RVC_JUMP if `h->plt.offset' isn't -1

[Palmer Dabbelt]

On Sat, 08 Feb 2025 00:33:37 PST (-0800), Nelson Chu wrote:

I got an request about the undefined behaviors, considering the following case,

$ cat test.c
void main ()
{
  foo();
}
$ cat lib.h
void foo(void);
$ riscv64-unknown-linux-gnu-gcc test.c
riscv64-unknown-linux-gnu/bin/ld: /tmp/ccRO8fJl.o: in function `main':
test.c:(.text+0x8): undefined reference to `foo'
collect2: error: ld returned 1 exit status
$ riscv64-unknown-linux-gnu-gcc test.c 
-Wl,--unresolved-symbols=ignore-in-object-files
$ qemu-riscv64 a.out
Segmentation fault (core dumped)

Testing with x86 and aarch64, they won't get the segfault since they go plt
for the undefined foo symbol.  So, after applying this patch, I can get the
following too,

$ qemu-riscv64 a.out
a.out: symbol lookup error: a.out: undefined symbol: foo

The change of this patch should only affect the call behavior, which refer
to an undefined (weak) symbol, when building an dynamic executable.  I think
the pic/pie behavior won't be affected as usual.  I am not sure if the change
will cause trouble or not for other projects, so please feels free to cc people
that you think they will be affected, thanks.


Thanks for doing this.  For some more context, there's a handful of Go 
plugins that seem to want `-Wl,--export-dynamic 
-Wl,--unresolved-symbols=ignore-in-object-files` to result in 
executables that have PLT-indirect calls to these undefined symbols, 
which they'll then later LD_PRELOAD or dlopen() to resolve.  Here's an  
example 
.


IMO that's pretty far into the realm of undefined behavior, and from 
poking around a bit it looks like that's the case even on x86 -- 
basically if my symbol gets linked before something has triggered a PLT 
to be created, then I end up with a direct reference that isn't 
dynamically resolvable.


It also looks like arm64 generates NOPs (rather than calls to absolute 
0) on these undefined symbols, so it's possible some instances of these 
are just crashing lazily.  THere might be some context floating around 
in 7cd2917227 ("aarch64: Return an error on conditional branch to an 
undefined symbol"), it's a bit hard to follow so I'm not sure if that's 
an intentional side-effect or just the easiest arbitrary thing to 
generate for this flavor of undefined behavior.


So I'm kind of split on what we should do here: in general I like to 
have undefined behavior crash eagerly, as otherwise we're just making 
these issues harder to debug.  That said, this has blown up internally 
and making it crash lazily will make the fire go out, and it'd be really 
nice to start a Monday morning with more fires going out than 
starting...


Maybe there's some more context floating around in someone's brain about 
this?



---
 bfd/elfnn-riscv.c | 84 +--
 1 file changed, 44 insertions(+), 40 deletions(-)

diff --git a/bfd/elfnn-riscv.c b/bfd/elfnn-riscv.c
index 57ced95fdb3..bca3a585f56 100644
--- a/bfd/elfnn-riscv.c
+++ b/bfd/elfnn-riscv.c
@@ -2263,6 +2263,7 @@ riscv_elf_relocate_section (bfd *output_bfd,
   reloc_howto_type *howto = riscv_elf_rtype_to_howto (input_bfd, r_type);
   const char *msg = NULL;
   bool resolved_to_zero;
+  bool via_plt = false;

   if (howto == NULL)
continue;
@@ -2565,6 +2566,12 @@ riscv_elf_relocate_section (bfd *output_bfd,
   resolved_to_zero = (h != NULL
  && UNDEFWEAK_NO_DYNAMIC_RELOC (info, h));

+  /* Refer to the PLT entry.  This check has to match the check in
+_bfd_riscv_relax_section.  */
+  via_plt = (htab->elf.splt != NULL
+&& h != NULL
+&& h->plt.offset != MINUS_ONE);
+
   switch (r_type)
{
case R_RISCV_NONE:
@@ -2776,8 +2783,7 @@ riscv_elf_relocate_section (bfd *output_bfd,
case R_RISCV_CALL_PLT:
  /* Handle a call to an undefined weak function.  This won't be
 relaxed, so we have to handle it here.  */
- if (h != NULL && h->root.type == bfd_link_hash_undefweak
- && (!bfd_link_pic (info) || h->plt.offset == MINUS_ONE))
+ if (h->root.type == bfd_link_hash_undefweak && !via_plt)
{
  /* We can use x0 as the base register.  */
  bfd_vma insn = bfd_getl32 (contents + rel->r_offset + 4);
@@ -2791,42 +2797,40 @@ riscv_elf_relocate_section (bfd *output_bfd,

case R_RISCV_JAL:
case R_RISCV_RVC_JUMP:
- if (bfd_link_pic (info) && h != NULL)
+ if (via_plt)
{
- if (h->plt.offset != MINUS_ONE)
-   {
- /* Refer to the PLT entry.  This check has to match the
-check in _bfd_riscv_relax_section.  */
- relocation = sec_addr (htab->elf.splt) + h->plt.offset;
- unresolved_reloc = false;
-   }
-