Re: [RFC] RISC-V: PR27916, Support mapping symbols.

[Nelson Chu <nelson.chu@sifive.com>]

Hi Palmer,

Sorry for the late reply, thanks for your suggestion :)

On Thu, Jun 3, 2021 at 12:18 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Fri, 28 May 2021 19:18:18 PDT (-0700), nelson.chu@sifive.com wrote:
> > Similar to ARM/AARCH64, we add mapping symbols in the symbol table,
> > to mark the start addresses of data and instructions.  The $d means data,
> > and the $x means instruction.  Then the disassembler uses these symbols
>
> We picked "__global_pointer$" under the assumption "$" would avoid any
> conflicts with symbols from user code, so these should be safe too.
> IIRC that's a normal way to do these things, and with Arm already having
> those names that seems like a good way to go.

Thanks for agreeing this.

> > TODOS,
> > * Need to add new directive, .inst 0x00000013, to show this is encoded as an
> > instruction, rather than a data.
>
> Maybe just an add explicit 4-byte NOP pseudo instruction or alias?  I
> keep finding myself in the position where I want to insert exactly 4
> bytes of NOP and the automatic compression gets in the way.

Oh, it may not be good to give the nop as example.  We have .insn
directive to let users can use their own instructions, or some new
instruction, which haven't supported in the old binutils.  For
example, if users want to use sifive cache instruction, they cannot
just write "cflush.d1.l1" and complied by the fsf binutils, but they
can write ".insn i SYSTEM, 0, x0, x10, -0x40".  But as you can see,
the .insn directive may not easy to use for some cases.  Therefore, I
believe most of the users are using ".word 0xfc050073" rather than the
.insn.  But if they always use ".word xxxxx" to encode their
instructions, then the mapping symbols will treat these .word as data
rather than instruction.  I see that arm defines .inst/.inst.w/.inst.n
to resolve the problem, so maybe we can follow this way.

> > * Consider RVC to NORVC, and DATA to INSN, we probably need to add the
> > alignments automatically by assembler.  But in fact the things that need
> > to be dealt with are more complicated than imagined.
>
> We've been through this a bunch of times and it always ends up somewhat
> hairy.  There's sort of this balance between trying to avoid inserting
> non-executable instructions -- either a single-byte NOP (for re-aligning
> on bytes) or a two-byte NOP outside of C (for re-aligning when turning
> off C).  IIRC we spent a lot of time trying to do a better job than
> we're currently doing and there were always enough edge cases that we
> decided to just make the user deal with these issues explicitly.
>
> If you've got an idea of how to do a better job I'm all ears, just
> warning that this might be more frusturation than it's worth.

Thanks, this issue really really frustrated me for a long time, haha.
The priority of this isn't high, so I just record it as one of the
TODO, and don't want to give up it.  Maybe someday, or someone will
have amazing ideas that surprise us.

> > * Consider the testcase mapping-norelax-04b.s, there is a c.nop which is
> > used to do the alignment, but the rvc extension is disabled.  This may
> > looks weird and confuse user, so maybe we should treat these alignments
> > as MAP_DATA rather than MAP_INSN?  Or maybe treat as a new MAP_ALIGNMNET?
>
> IMO that's the right way to go here.  The C instructions aren't valid
> without the C ISA, so they're not really quite instructions at that
> point.  As above there's always been a bunch of rough edges around this
> sort of thing, though, so it might be hard to make this work without
> causing a headache somewhere else.

Yeah, just consider one of these issue may be fine, but if we consider
all of them at the same time, then things will start to get out of
control...


Thanks again for the feedback
Nelson