public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Vladimir Makarov <vmakarov@cygnus.com>
To: Ian Lance Taylor <ian@zembu.com>
Cc: rth@cygnus.com, binutils@sourceware.cygnus.com
Subject: Re: Patch for gas (mri mode).
Date: Mon, 20 Sep 1999 13:05:00 -0000	[thread overview]
Message-ID: <37E69334.FEBB609F@cygnus.com> (raw)
In-Reply-To: <19990920180506.21546.qmail@daffy.airs.com>

Ian Lance Taylor wrote:

>    Date: Mon, 20 Sep 1999 13:41:55 -0400
>    From: Vladimir Makarov <vmakarov@tootie.to.cygnus.com>
>
>    The following patch is relative to net binutils repository.  Please,
>    approve it or not.  Without the patch, the assembler code likes the
>    following results in assembler crash because in MRI mode the assembler
>    does not define NARG, but in non-MRI mode the assembler expects that
>    NARG is defined.
>
> That's backward: NARG is defined and expected to exist in MRI mode.
>
> If we think that a macro defined in MRI mode should operate as an
> MRI-style macro, then quite a few more instances of macro_mri need to
> change.  In fact, we probably need to push and pop the global variable
> flag_mri during the macro expansion.
>
> If we just want to fix the particular problem at hand, I think it
> would be clearer to simply check the result of hash_find for NULL,
> rather than consider a macro to be in MRI mode or not.
>

Ian, I thought about this solution.  I've chosen the previous solution.  I
believed that it is clearer because it says clearly about the situation of
usage of macro defined in mri mode and used in non-macro mode (and vise
versa).  It could be useful for anyone who will add code (e.g. new implicit
args) in order to miss the situation because he/she will see new member in
the struct macro.  It could be safer because if something is wrong with the
code with implicit definition of NARG, we will miss the bug because we 'll
think that is defined in mri mode.  Now I see that there are many awkward
situations with .mri usage (e.g. treatment of usage of .mri in macros
themselves).

So, now I'd prefer the simple solution.  Here the new patch is.  Please,
approve it or not.


1999-09-20  Vladimir Makarov  <vmakarov@tootie.to.cygnus.com>

        * macro.c (macro_expand): Expand NARG only if it is defined.

Index: macro.c
===================================================================
RCS file: /cvs/binutils/binutils/gas/macro.c,v
retrieving revision 1.2
diff -c -p -r1.2 macro.c
*** macro.c     1999/06/03 00:23:27     1.2
--- macro.c     1999/09/20 19:37:52
*************** macro_expand (idx, in, m, out, comment_c
*** 1063,1071 ****
        sb_reset (&t);
        sb_add_string (&t, macro_strip_at ? "$NARG" : "NARG");
        ptr = (formal_entry *) hash_find (m->formal_hash, sb_terminate
(&t));
!       sb_reset (&ptr->actual);
!       sprintf (buffer, "%d", narg);
!       sb_add_string (&ptr->actual, buffer);
      }

    err = macro_expand_body (&m->sub, out, m->formals, m->formal_hash,
--- 1063,1075 ----
        sb_reset (&t);
        sb_add_string (&t, macro_strip_at ? "$NARG" : "NARG");
        ptr = (formal_entry *) hash_find (m->formal_hash, sb_terminate
(&t));
!       /* ptr == NULL means that macro is defined not in mri mode. */
!       if (ptr != NULL)
!       {
!         sb_reset (&ptr->actual);
!         sprintf (buffer, "%d", narg);
!         sb_add_string (&ptr->actual, buffer);
!       }
      }

    err = macro_expand_body (&m->sub, out, m->formals, m->formal_hash,


  reply	other threads:[~1999-09-20 13:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-20 10:43 Vladimir Makarov
1999-09-20 10:59 ` Richard Henderson
1999-09-20 11:03   ` Vladimir Makarov
1999-09-20 11:06 ` Ian Lance Taylor
1999-09-20 13:05   ` Vladimir Makarov [this message]
1999-09-20 13:51     ` Ian Lance Taylor

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=37E69334.FEBB609F@cygnus.com \
    --to=vmakarov@cygnus.com \
    --cc=binutils@sourceware.cygnus.com \
    --cc=ian@zembu.com \
    --cc=rth@cygnus.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).