public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Tom de Vries <tdevries@suse.de>, Tom Tromey <tom@tromey.com>,
	Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH][gdb/testsuite] Support .debug_aranges in dwarf assembly
Date: Sun, 29 Aug 2021 15:54:42 -0400	[thread overview]
Message-ID: <f4419fdd-6ddb-1e30-89e1-23d8003a740a@polymtl.ca> (raw)
In-Reply-To: <c5d05bd3-0b68-e983-e257-05864803f0a3@suse.de>

> OK, I've integrated the subst bit (and made it conditional, that was
> still missing).  Also added the subst part for the default arguments,
> and added a proper log message.  Any further comments?

LGTM.

> [ FWIW, a bit of bike-shedding.  I could imagine a pattern where you
> pair a proc <name> and <name>_ like this:
> ...
>   proc arange_ { options start len } {
>     ...
>   }
>   proc arange { start len } {
>     arange_ {} start len
>   }
> ...
> to be able to do:
> ...
>   arange $start $len
> ...
> and:
> ...
>   arange_ { comment "bla" } $start $len
> ...
> which would be slightly less annoying that having to specify empty
> options. ]

I don't mind either way.  Even nicer would be to allow both:

  arange $start $len
  arange { comment "bla" } $start $len

But that would probably require going back to using args, which breaks
the purpose of what you're doing here.

Just to understand how we can do this in a systematic and predictable
way, would you do it just for "arange" or would you do it for all procs
of this style, like "cu"?  In some cases (like cu), the case of having
options is more common than the case of not having options.  So would
you still have "cu" without options and "cu_" with options?

Simon

  reply	other threads:[~2021-08-29 19:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-26 11:56 Tom de Vries
2021-08-27 13:35 ` Tom Tromey
2021-08-27 14:39   ` Tom de Vries
2021-08-27 15:09   ` Simon Marchi
2021-08-27 16:11     ` Keith Seitz
2021-08-27 16:14     ` Tom Tromey
2021-08-27 17:03       ` Simon Marchi
2021-08-27 17:10         ` Tom Tromey
2021-08-27 17:23           ` Simon Marchi
2021-08-28 15:31     ` Tom de Vries
2021-08-28 20:29       ` Simon Marchi
2021-08-28 21:28         ` Simon Marchi
2021-08-29 15:31           ` Tom de Vries
2021-08-29 19:54             ` Simon Marchi [this message]
2021-08-29 21:11               ` Tom de Vries
2021-08-30  8:35               ` Tom de Vries

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=f4419fdd-6ddb-1e30-89e1-23d8003a740a@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=tdevries@suse.de \
    --cc=tom@tromey.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).