public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@dabbelt.com>
To: jbeulich@suse.com
Cc: binutils@sourceware.org, Andrew Waterman <andrew@sifive.com>,
	Jim Wilson <jim.wilson.gcc@gmail.com>,
	nelson@rivosinc.com
Subject: Re: [PATCH RFC] RISC-V: alter the special character used in FAKE_LABEL_NAME
Date: Wed, 15 Mar 2023 09:05:14 -0700 (PDT)	[thread overview]
Message-ID: <mhng-3f889372-9d31-4b3e-a17f-975f87426938@palmer-ri-x1c9a> (raw)
In-Reply-To: <150b4184-62af-3f5c-c07b-24b0c2ae788f@suse.com>

On Fri, 10 Mar 2023 01:36:31 PST (-0800), jbeulich@suse.com wrote:
> The use of a space char there collides with anything using temp_ilp(),
> i.e. at present at least with the special % operator available in
> alternate macro mode. Further uses of the function may appear at any
> time. This likely is a result of write.h's comment not properly
> spelling out all the constraints placed on the selection of the special
> character used. Then again RISC-V anyway violates a constraint which has
> been properly spelled out there: Such labels _do_ appear in assembler
> output.
> ---
> RFC: Of course this breaks interoperability between older gas / new
>      objdump and vice versa. But I don't see a way to resolve the issue
>      at hand without introducing such a discontinuity. To limit "damage"
>      a little, riscv_symbol_is_valid() could of course be tought to also
>      ignore old style fake label names. (Personally I view this tying of
>      functionality between assembler and disassembler as problematic
>      anyway.) Thoughts?

This wouldn't be the first time we've made a change around here in 
RISC-V land, see 2469b3c5844 ("Riscv ld-elf/stab failure and fake label 
cleanup.").  Unless I'm missing something we maintained compatibility 
with the old binaries there, I'd prefer if we can do that here too.  
That said...

> I question the use of FAKE_LABEL_NAME in make_internal_label(). The
> comment in tc-riscv.h isn't correct anyway because of (at least) this
> use - the symbols generated there are never used for Dwarf. And them all
> being the same makes it rather hard to associate relocations resolved to
> symbol names (e.g. "objdump -dr" output) with the actual instance that's
> referenced. Their naming should imo rather follow the model of
> {fb,dollar}_label_name().
>
> Considering the special casing of FAKE_LABEL_CHAR in read_symbol_name()
> and get_symbol_name() I wonder in how far LOCAL_LABEL_CHAR and/or
> DOLLAR_LABEL_CHAR don't also need recognizing there (and then also be
> marked in lex[] just like done here). I can't point out a specific case
> though where there could be a problem.
>
> The checking for *_LABEL_CHAR in S_IS_LOCAL() looks to collide with uses
> of these characters in quoted symbol names.

... if this is all broken anyway then I guess compatibility doesn't 
matter that much?  I've definately seen some oddness around here, but I 
think it generally works.

> --- a/gas/app.c
> +++ b/gas/app.c
> @@ -200,6 +200,11 @@ do_scrub_begin (int m68k_mri ATTRIBUTE_U
>    lex['-'] = LEX_IS_SYMBOL_COMPONENT;
>  #endif
>
> +  /* If not otherwise used (which it shouldn't be - see write.h), mark the
> +     fake label character as a possible part of symbol names.  */
> +  if (!lex[(unsigned char) FAKE_LABEL_CHAR])
> +    lex[(unsigned char) FAKE_LABEL_CHAR] = LEX_IS_SYMBOL_COMPONENT;
> +
>  #ifdef H_TICK_HEX
>    if (enable_h_tick_hex)
>      {
> --- a/gas/config/tc-riscv.h
> +++ b/gas/config/tc-riscv.h
> @@ -38,8 +38,7 @@ struct expressionS;
>  #define LOCAL_LABELS_FB 	1
>
>  /* Symbols named FAKE_LABEL_NAME are emitted when generating DWARF, so make
> -   sure FAKE_LABEL_NAME is printable.  It still must be distinct from any
> -   real label name.  So, append a space, which other labels can't contain.  */
> +   sure FAKE_LABEL_NAME is printable.  See write.h for constraints.  */
>  #define FAKE_LABEL_NAME RISCV_FAKE_LABEL_NAME
>  /* Changing the special character in FAKE_LABEL_NAME requires changing
>     FAKE_LABEL_CHAR too.  */
> --- a/gas/testsuite/gas/all/altmacro.d
> +++ b/gas/testsuite/gas/all/altmacro.d
> @@ -8,4 +8,4 @@
>
>  Contents of section .data:
>   0000 01020912 61626331 32332121 3c3e2721 .*
> - 0010 3c3e27.*
> + 0010 3c3e27a2 11.*
> --- a/gas/testsuite/gas/all/altmacro.s
> +++ b/gas/testsuite/gas/all/altmacro.s
> @@ -33,3 +33,9 @@ m4	"!!<>'"
>  	.altmacro
>
>  m3	"!!<>'"
> +
> +	.macro	m2b v1, v2
> +	m1 %v2-v1 17
> +	.endm
> +
> +	m2b 81 243
> --- a/gas/write.h
> +++ b/gas/write.h
> @@ -30,7 +30,8 @@
>  /* This is a special character that is used to indicate a fake label.
>     It must be present in FAKE_LABEL_NAME, although it does not have to
>     be the first character.  It must not be a character that would be
> -   found in a valid symbol name.
> +   found in a valid symbol name, nor one that starts an operator, nor
> +   one that's a separator of some kind.
>
>     Also be aware that the function _bfd_elf_is_local_label_name in
>     bfd/elf.c has an implicit assumption that FAKE_LABEL_CHAR is '\001'.
> --- a/include/opcode/riscv.h
> +++ b/include/opcode/riscv.h
> @@ -323,9 +323,10 @@ static inline unsigned int riscv_insn_le
>
>  /* These fake label defines are use by both the assembler, and
>     libopcodes.  The assembler uses this when it needs to generate a fake
> -   label, and libopcodes uses it to hide the fake labels in its output.  */
> -#define RISCV_FAKE_LABEL_NAME ".L0 "
> -#define RISCV_FAKE_LABEL_CHAR ' '
> +   label, and libopcodes uses it to hide the fake labels in its output.
> +   See gas/write.h for constraints.  */
> +#define RISCV_FAKE_LABEL_NAME ".L0?"
> +#define RISCV_FAKE_LABEL_CHAR '?'
>
>  /* Replace bits MASK << SHIFT of STRUCT with the equivalent bits in
>     VALUE << SHIFT.  VALUE is evaluated exactly once.  */

  parent reply	other threads:[~2023-03-15 16:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-10  9:36 Jan Beulich
2023-03-10  9:40 ` Jan Beulich
2023-03-13 12:06   ` Nick Clifton
2023-03-13 12:52     ` Jan Beulich
2023-03-13 14:25       ` Nick Clifton
2023-03-13 15:57         ` Jan Beulich
2023-03-15 11:08           ` Nick Clifton
2023-03-15 15:45             ` Jan Beulich
2023-03-15 16:05 ` Palmer Dabbelt [this message]
2023-03-16 10:35   ` Jan Beulich
2023-03-30 12:01 ` Jan Beulich
2023-08-04 12:04   ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=mhng-3f889372-9d31-4b3e-a17f-975f87426938@palmer-ri-x1c9a \
    --to=palmer@dabbelt.com \
    --cc=andrew@sifive.com \
    --cc=binutils@sourceware.org \
    --cc=jbeulich@suse.com \
    --cc=jim.wilson.gcc@gmail.com \
    --cc=nelson@rivosinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).