public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	Andrew Waterman <andrew@sifive.com>,
	Jim Wilson <jim.wilson.gcc@gmail.com>,
	Nelson Chu <nelson@rivosinc.com>,
	Binutils <binutils@sourceware.org>, Alan Modra <amodra@gmail.com>
Subject: Re: [PATCH RFC] RISC-V: alter the special character used in FAKE_LABEL_NAME
Date: Mon, 13 Mar 2023 14:25:58 +0000	[thread overview]
Message-ID: <f9b5df46-f88b-7773-9cb8-dda87d646dd8@redhat.com> (raw)
In-Reply-To: <0a576110-624b-6339-b24d-907d6df72e09@suse.com>

Hi Jan,

> What I don't think you addressed is my 2nd observation wrt quoted symbol
> names. There all characters can appear in symbol names, and hence
> deriving "local" (or not) based on symbol name looks wrong to me.

Ok, that is fair.  Let's see.  So the issue is, what should S_IS_LOCAL do
if a user provides a global, quoted symbol name that includes characters
that match DOLLAR_LABEL_CHAR, LOCAL_LABEL_CHAR or FAKE_LABEL_CHAR, right ?

I would imagine that this is an extremely unusual case, which is why it has
not come up before.

First off, I wonder why S_IS_LOCAL does not check to see if BSF_GLOBAL is
set in flags and return false if that is the case.  If it did, I think that
that would solve the problem.  I cannot think of any situation where you
could have a global symbol that needs to be treated as local for the purposes
of S_IS_LOCAL.

Alternatively, maybe it would be simpler to just document that quoted
symbol names that contain special characters might be treated as if they
were local symbols, and leave it up to the user to decide whether they
want to risk such behaviour.  Not very user friendly, but it would match
the current behaviour.  We could also add a warning to read_symbol_name()
and get_symbol_name() to alert users to the problem.

What do you think ?  Any preferences ?

Cheers
   Nick




  reply	other threads:[~2023-03-13 14:26 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 [this message]
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
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=f9b5df46-f88b-7773-9cb8-dda87d646dd8@redhat.com \
    --to=nickc@redhat.com \
    --cc=amodra@gmail.com \
    --cc=andrew@sifive.com \
    --cc=binutils@sourceware.org \
    --cc=jbeulich@suse.com \
    --cc=jim.wilson.gcc@gmail.com \
    --cc=nelson@rivosinc.com \
    --cc=palmer@dabbelt.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).