A subsequent patch needs to move an addrmap. This patch adds the
necessary support. It also changes addrmap_fixed to take a 'const'
addrmap_mutable. This is fine according to the contract of
addrmap_mutable; but it did require a compensating const_cast in the
implementation.
Currently the DWARF scanner will enter enumeration constants into the
same namespace as the DW_TAG_enumeration_type itself. This is the
right thing to do, but the implementation may result in strange
entries being added to the addrmap that maps DIE ranges to entries.
This came up when debugging an earlier version of this series; and
while I don't think this should impact the current series, it seems
better to clean this up anyway.
In the new code, rather than pass the "wrong" scope down through
recursive calls to the scanner, the correct scope is always passed,
and then the parent handling is done when creating the enumerator
entry.
In scan_attributes there's code:
...
if (new_reader->cu == reader->cu
&& new_info_ptr > watermark_ptr
&& *parent_entry == nullptr)
...
else if (*parent_entry == nullptr)
...
...
that uses the "*parent_entry == nullptr" condition twice.
Make this somewhat more readable by factoring out the condition:
...
if (*parent_entry == nullptr)
{
if (new_reader->cu == reader->cu
&& new_info_ptr > watermark_ptr)
...
else
...
}
...
This also allows us to factor out "form_addr (origin_offset, origin_is_dwz)".
Tested on x86_64-linux.
I suppose this was needed when we had `void` in declarations of methods
with no parameters. If so, we no longer need it. There are no changes
in the generated file.
Change-Id: I0a2b398408aa129634e2d73097a038f7f80db4b4
Approved-By: John Baldwin <jhb@FreeBSD.org>
I've noticed that doc strings of some commands, like "set cwd"
and "set inferior-tty", have some excess whitespace, which
makes them display with unexpected indentation, at least in a
Windows command prompt window. This patch fixes that.
* gdb/linux-nat.c (_initialize_linux_nat):
* gdb/riscv-tdep.c (riscv_insn):
* gdb/top.c (quit_force):
* gdb/infcmd.c (_initialize_infcmd): Remove excess whitespace.
PR python/31631 reports a gdb internal error when doing:
...
(gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)
utils.c:709: internal-error: virtual memory exhausted.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
...
Fix this by throwing a python MemoryError, such that we have instead:
...
(gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)
Python Exception <class 'MemoryError'>:
Error occurred in Python.
(gdb)
...
Likewise for DAP.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31631
commit bdcd50f9 ("Strip trailing newlines from input string")
introduced a crash in eof-exit.exp. This patch fixes the problem by
adding a NULL check in the appropriate spot.
Regression tested on x86-64 Fedora 38. I'm checking this in.
I noticed that add_using_directive's 'copy_names' parameter is only
used by a single caller. This patch removes the parameter and changes
that caller to copy the names itself. I chose to use intern here
since I suspect the names may well be repeated in a given objfile.
Approved-By: John Baldwin <jhb@FreeBSD.org>
commit e8cd90f0 ("Rewrite gdb_bfd_error_handler") broke the clang
build.
The problem here is that print_error_callback isn't marked as being
printf-like, but it calls string_file::vprintf, triggering:
../../binutils-gdb/gdb/gdb_bfd.c:1202:18: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
This patch applies the attribute to this function.
It also removes the attribute from gdb_bfd_error_handler, because that
function is no longer really printf-like.
The mingw build currently issues a warning:
./../../src/gdb/utils.h:378:56: warning: ignoring attributes on template argument 'void(const char*, va_list)' {aka 'void(const char*, char*)'} [-Wignored-attributes]
This patch fixes the problem as suggested by Simon:
https://sourceware.org/pipermail/gdb-patches/2024-April/207908.html
...that is, by changing the warning interceptor to a class with a
single 'warn' method.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
A co-worker noticed a strange situation where "target remote" would
fail due to a trailing newline in the address part of the command.
Eventually he tracked this down to the fact that he was pasting the
command into the terminal, and due to bracketed paste mode, the
newline was being preserved by readline.
It seems to me that we basically never want a trailing newline on a
gdb command, so this patch removes it when handling the readline
result.
Co-Authored-By: Kévin Le Gouguec <legouguec@adacore.com>
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
Currently, when the current thread is running, you can print global
variables. However, if you try to set a watchpoint on the same
globals, GDB errors out, complaining that the selected thread is
running. Like so:
(gdb) c&
Continuing.
(gdb) p global
$1 = 1098377287
(gdb) watch global
Selected thread is running.
This patch makes setting the watchpoint work. You'll now get:
(gdb) c&
Continuing.
(gdb) [New Thread 0x7ffff7d6e640 (LWP 434993)]
[New Thread 0x7ffff756d640 (LWP 434994)]
p global
$1 = 88168
(gdb) watch global
Hardware watchpoint 2: global
(gdb) [Switching to Thread 0x7ffff7d6e640 (LWP 434993)]
Thread 2 "function0" hit Hardware watchpoint 2: global
Old value = 185420
New value = 185423
int_return () at threads.c:39
39 }
The problem is that update_watchpoint calls get_selected_frame
unconditionally. We can skip it if the watchpoint expression is only
watching globals.
This adds a testcase that exercises both all-stop and non-stop, and
also software and hardware watchpoints. It is kfailed for software
watchpoints, as those require another fix not handled by this patch
(the sw watchpoint doesn't fire because GDB doesn't force the
running-free thread to switch to single-stepping).
Change-Id: I68ca948541aea3edd4f70741f272f543187abe40
On Cygwin, the gdb.base/fork-no-detach-follow-child-dlopen.exp
testcase hits a sequence of cascading FAILs:
(gdb) run
Starting program: ..../gdb.base/fork-no-detach-follow-child-dlopen/fork-no-detach-follow-child-dlopen
[New Thread 12672.0x318c]
[New Thread 12672.0x2844]
[New Thread 12672.0x714]
FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: runto: run to add (timeout)
frame
FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: frame (timeout)
list
FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: list (timeout)
And the test program never makes progress.
... and at this point, Cygwin is completely stuck. I can't run any
other Cygwin program.
However, if we run the test program outside DejaGnu, we see something
different:
(gdb) b add
Function "add" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (add) pending.
(gdb) r
Starting program: ..../gdb.base/fork-no-detach-follow-child-dlopen/fork-no-detach-follow-child-dlopen
[New Thread 10968.0x834]
[New Thread 10968.0x29a4]
[New Thread 10968.0x16b8]
[New Thread 10968.0xf9c]
[Switching to Thread 10968.0x16b8]
Thread 4 "sig" hit Breakpoint 1.2, pending_signals::add (pack=..., this=0x7ffa1e748a40 <sigq>) at /usr/src/debug/cygwin-3.4.9-1/winsup/cygwin/sigproc.cc:1304
1304 se = sigs + pack.si.si_signo;
(gdb)
Ah, the test wanted to run to a global "add" function, but managed to
stop at an internal Cygwin method called "add". And stopping there
deadlocks everything Cygwin in the system. (I believe some
cygwin1.dll mechanisms use cross-process synchronization or
communication, we're probably blocking something like that.)
Fix this by using "break -q". The tests FAIL because we don't support
follow-fork for Cygwin, but at least we no longer deadlock the
machine.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I7181d8481c2ae1024b0d73e3bb194f9a4f0a7eb9
After my recent changes the data-directory build now uses
silent-rules.mk to reduce the output.
One problem that remains was the use of mkinstalldirs by stamp-python
and stamp-guile for creating some directories, the mkinstalldirs
prints some messages, so we're left with output like this:
GEN stamp-python
mkdir -p -- ./python/gdb
mkdir -p -- ./python/gdb/command
mkdir -p -- ./python/gdb/dap
mkdir -p -- ./python/gdb/function
mkdir -p -- ./python/gdb/printer
I was looking at adding a --silent option to the mkinstalldirs script,
however, when I took a look at the automake package (which is where
mkinstalldirs comes from) it turns out that mkinstalldirs is
deprecated, at the advice is to use 'install-sh -d' instead.
Just like we carry mkinstalldirs in the top-level directory, we also
carry install-sh, and a version of install-sh which supports the -d
flag.
And best of all, 'install-sh -d' doesn't appear to print any of the
information messages to stdout that mkinstalldirs does, so if we
switch to use that, we get a quieter build.
There should be no changes in what is built after this commit
Approved-By: Tom Tromey <tom@tromey.com>
When running test-case gdb.threads/access-mem-running-thread-exit.exp with
clang, we run into:
...
(gdb) print global_var = 555^M
No symbol "global_var" in current context.^M
(gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: all-stop: \
access mem (write to global_var, inf=2, iter=1)
...
The problem is that clang removes the unused variable.
Fix this in the same way as done in commit b4f767131f
("Fix gdb.base/align-*.exp and Clang + LTO and AIX GCC"), by incrementing the
variable.
Tested on x86_64-linux with gcc and clang.
For some reason install-dvi is missing although other targets of the
same family are present. This looks like an oversight.
This enables calling 'make install-dvi' from the top-level build
directory.
Fix what looks like another oversight: include 'pdf' in 'all-doc' in
gdb/doc/Makefile.in.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
This patch rewrites gdb_bfd_error_handler to use 'bfd_print_error' to
generate the text of the warning, and then emits it using 'warning'.
The current code in the tree is a bit wrong because it may do the
wrong thing when BFD uses ones of its printf extensions.
This also adds locking to increment_bfd_error_count. This is
important now that some BFD operations can be done on worker threads.
This approach makes it simpler for worker threads to intercept any
messages.
Regression tested on x86-64 Fedora 38.
This allows the error message stored in a packet_result to be easily
printed in the calling function.
Approved-By: Andrew Burgess <aburgess@redhat.com>
when processing the GDBserver reply to qRcmd packet.
Print error message or the error code.
Currently, when qRcmd request returns an error,
GDB just prints:
Protocol error with Rcmd
After this change, GDB will also print the error code:
Protocol error with Rcmd: 01.
Add an accept_msg argument to packet_check result. qRcmd
request (such as many other packets) does not recognise
"E.msg" form as an error right now. We want to recognise
"E.msg" as an error response only for the packets where
it's documented.
Also use packet_check result in remote_read_bytes_1.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Following the suggestion in this review comment:
https://inbox.sourceware.org/gdb-patches/9420bbb0-2614-4847-9157-8562f8a62d03@simark.ca
this commit realigns the AC_ARG_ENABLE(sim, ....) block. I've added
additional [...] quoting in a couple of places, which is inline with
how other AC_ARG_ENABLE blocks are formatted within GDB's configure.ac
file.
There should be no change in how GDB configures or builds after this
commit.
This commit makes use of gdb/silent-rules.mk in the data-directory
Makefile.in. I've only updated the rules that actually generate
things, I've not touched the install or uninstall rules, this matches
gdb/Makefile.in.
I've not managed to completely silence all of the recipe output, the
mkinstalldirs command outputs some diagnostic text which looks like
this:
GEN stamp-python
mkdir -p -- ./python/gdb
mkdir -p -- ./python/gdb/command
mkdir -p -- ./python/gdb/dap
mkdir -p -- ./python/gdb/function
mkdir -p -- ./python/gdb/printer
I have a patch for mkinstalldirs that fixes this (by adding a new
--silent command line flag), but that patch needs to be submitted to
automake, then an updated mkinstalldirs sync'd to the gcc repository,
and then copied into the binutils-gdb repository... so I'm leaving
that for a future project.
Then the guild compiler also emits some diagnostic output, which looks
like this:
GEN stamp-guile
mkdir -p -- ./guile/.
mkdir -p -- ./guile/gdb
wrote `./gdb.go'
wrote `gdb/experimental.go'
wrote `gdb/iterator.go'
wrote `gdb/printing.go'
wrote `gdb/support.go'
wrote `gdb/types.go'
The 'wrote' lines are from the guild compiler. The only way to
silence these would be to redirect stdout to /dev/null I think. I did
prototype this, but wasn't 100% convinced about that part of the
patch, so I've decided to leave that for another day.
I did need to add a new SILENT_ECHO variable to silent-rules.mk, this
is set to a suitable 'echo' command to use within recipes. When we
are in silent mode then I use the 'true' command, while in verbose
mode we actually use 'echo'.
So, other than the issues outlined above, the output when building the
data-directory is now greatly reduced, and more inline with the output
when building in the gdb/ directory.
There should be no change in what is actually built after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
After the recent commits, I noticed that GDB's configure script would
still emit two lines even when run in silent mode. If you touch
gdb/Makefile.in and then run 'make all' in the gdb/ build directory
you'll see this:
GEN config.status
enable_sim = no
enableval = no
Obviously the 'no' might be 'yes' depending on how you actually
configured GDB.
This is caused by two direct invocations of 'echo' in GDB's
configure.ac script.
In this commit I replace these calls with use of AC_MSG_NOTICE
instead. Now when configure is run with the --silent command line
option these lines will not be printed.
There should be no changes in the built GDB after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The targets that use config.status to regenerate themselves don't
currently follow the silent rules that the rest of GDB's Makefile
does. For example, touch the gdb/gcore.in file and then 'make all' in
the gdb/ directory prints:
/bin/sh config.status gcore
config.status: creating gcore
In this commit I make use of the silent-rules.mk mechanism for these
targets, now we get:
GEN gcore
Which matches the rest of our Makefile. Obviously, if you pass 'V=1'
to the build then you'll get the old output back.
There's no change in what is generated after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
I noticed that for the build targets jit-reader.h, gcore, gdb-gdb.py,
and gdb-gdb.gdb the rules all use the config.status script, but don't
have a dependency on the config.status target. This means we might
fail to regenerate these targets in a case where config.status, or one
of its dependencies changes.
Two other targets that use config.status do correctly have a
dependency on config.status.
Fixed in this commit by adding the missing dependencies.
There should be no changes in _what_ is generated after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
I noticed something weird, the rule for the config.status target looks
like this:
config.status: $(srcdir)/configure configure.nat configure.tgt configure.host ../bfd/development.sh
$(SHELL) config.status --recheck
What bothered me is that 'configure' is specified as being in
$(srcdir), while all of the other files are not, even though those
files are in the same $(srcdir) as the configure script.
However, I tried touching one of those files, and the config.status
rule does trigger!
This is thanks to the VPATH variable, which is set to $(srcdir), so
make looks in $(srcdir) for any dependencies.
However, this inconsistency bothers me. Better, I think, to add the
$(srcdir) prefix to each of these files.
I also spotted that the configure script also includes the files
../bfd/config.bfd, yet that is missing from the include list, so in
this commit I plan to add this as a dependency.
The configure script also pulls in two TCL and TK related files:
. ${TCL_BIN_DIR}/tclConfig.sh
. ${TK_BIN_DIR}/tkConfig.sh
However, I don't think ${TCL_BIN_DIR} and ${TK_BIN_DIR} are currently
visible in GDB's Makefile, so I'm not planning to add these
dependencies at this time.
In this commit I add a new variable config_status_deps which holds the
list of all the dependencies for config.status, with the $(srcdir)
prefix included, and then I use this in the config.status rule.
After this commit config.status will regenerate if config.bfd changes,
which it wouldn't before, but nothing else changes.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The gcore script is initially generated by the configure process, just
like gdb-gdb.gdb and gdb-gdb.py. However if the gdb/gcore.in input
source is modified then 'make all' in the gdb/ directory does not
regenerate the gcore script.
This is different than the gdb-gdb.gdb and gdb-gdb.py files, if their
input is updated then 'make all' will regenerate these files.
The difference is that for gdb-gdb.* there is an explicit dependency
between the 'all' target and the generated file, this dependency is
missing for gcore.
This commit adds the dependency. Now, if gcore.in is changed, running
'make all' will regenerate the gcore script.
There is no change in _what_ is generated after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
When building GDB on Centos 7 (which has flex 2.5.37) and Clang, I get:
$ make ada-exp.o
YACC ada-exp.c
LEX ada-lex.c
CXX ada-exp.o
In file included from /home/smarchi/src/binutils-gdb/gdb/ada-exp.y:1179:
<stdout>:1106:2: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
1106 | register yy_state_type yy_current_state;
| ^~~~~~~~
In ada-lex.l, we already use `DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER`,
which for Clang translates to ignoring `-Wdeprecated-register` [1]. I think
that was produced when compiling as C++11, but now that we always compile as
C++17, Clang produces a `-Wregister` error [2].
For GCC, `DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER` already translates to
ignoring `-Wregister`. So, rename
`DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER` to `DIAGNOSTIC_IGNORE_REGISTER`
and ignore `-Wregister` for Clang too.
[1] https://releases.llvm.org/17.0.1/tools/clang/docs/DiagnosticsReference.html#wdeprecated-register
[2] https://releases.llvm.org/17.0.1/tools/clang/docs/DiagnosticsReference.html#wregister
include/ChangeLog:
* diagnostics.h (DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER): Rename
to...
(DIAGNOSTIC_IGNORE_REGISTER): ... this. Ignore `-Wregister`
instead of `-Wdeprecated-register`.
Change-Id: I8a4a51c7222c68577fa22ecacdddfcba32d9dbc5
This adds flake8 and isort to .pre-commit-config.yaml. This way, they
will automatically be run on commit.
I chose the most recent available versions after verifying that they
don't cause any reports or changes in the current tree.
Internally at AdaCore, we also use a few flake8 plugins as well, so
perhaps that's another avenue for investigation.
v2: Also update the various file-selection clauses to pick up
gdb-gdb.py.in; include the isort change made to this file; and finally
add a comment about the exclusions from flake8.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
When the XML support was disabled at compile time,
the test case gdb.threads/stepi-over-clone.exp fails
with lots of time-outs, which can be annoying.
This makes the test case unsupported instead.
Approved-By: Tom Tromey <tom@tromey.com>
The XML response to the "qXfer:threads:read" packet may include
a "handle" attribute. The attribute is mentioned in the document
but not shown in the sample XML structure. Add it.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
In a previous review, I noticed that some code in gdb/compile/compile.c
could use c++17's `std::filesystem::remove_all` instead of using some
`system ("rm -rf ...");`.
This patch implements this.
Note that I use the noexcept overload of std::filesystem::remove_all and
explicitly check for an error code. This means that this code called
during the cleanup procedure cannot throw, and does not risk preventing
other cleanup functions to be called.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31420
Change-Id: If5668bf3e15e66c020e5c3b4fa999f861690e4cf
Approved-By: Tom Tromey <tom@tromey.com>
I recent change (e9b738dfbd "Avoid race when reading dwz file") moved
the call to dwarf2_read_dwz_file from dwarf2_initialize_objfile to
dwarf2_has_info.
Before that patch, dwarf2_initialize_objfile was only called when
dwarf2_has_info returned true, and since that patch it is always called.
When reading a file that has no debug info (.debug_info/.debug_abbrev
sections), but has a .gnu_debugaltlink section, GDB’s behavior is
different. I can observe this when loading
/lib/x86_64-linux-gnu/libtinfo.so on Ubuntu 22.04 (or while debugging
any program dynamically loading this library).
Before e9b738dfbd, we had:
$ ./gdb/gdb -data-directory ./gdb/data-directory -q /lib/x86_64-linux-gnu/libtinfo.so
Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so...
(No debugging symbols found in /lib/x86_64-linux-gnu/libtinfo.so)
(gdb)
while after we have:
$ ./gdb/gdb -data-directory ./gdb/data-directory -q /lib/x86_64-linux-gnu/libtinfo.so
Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so...
warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/libtinfo.so.6.3
(No debugging symbols found in /lib/x86_64-linux-gnu/libtinfo.so)
(gdb)
This patch restores the previous behavior of only trying to load the
DWZ file for objfiles when the main part of the debuginfo is present
(i.e. when dwarf2_has_info returns true). We still make sure that
dwarf2_read_dwz_file is called at most once per objfile.
A consequence of this change is that the per_bfd->dwz_file optional
object can now remain empty (instead of containing a nullptr), so also
this patch also adjusts dwarf2_get_dwz_file to account for this
possibility. This effectively reverts the changes to
dwarf2_get_dwz_file done by e9b738dfbd.
Regression tested on x86_64-linux-gnu Ubuntu 22.04.
Approved-By: Tom Tromey <tom@tromey.com>
Investigating GDB PR d/31580 showed that the libiberty demangler
doesn't automatically demangle D mangled names. However, I think it
should -- like C++ and Rust (new-style), D mangled names are readily
distinguished by the leading "_D", and so the likelihood of confusion
is low. The other non-"auto" cases in this code are Ada (where the
encoded form could more easily be confused by ordinary programs) and
Java (which is long gone, but which also shared the C++ mangling and
thus was just an output style preference).
This patch also fixed another GDB bug, though of course that part
won't apply to the GCC repository.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31580
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30276
libiberty
* cplus-dem.c (cplus_demangle): Try the D demangler with
"auto" format.
* testsuite/d-demangle-expected: Add --format=auto test.
The recent change to how unsized Rust values are printed included a
small regression from past behavior. Previously, a slice's type would
be printed, like:
(gdb) print slice
$80 = &[i32] [3]
The patch changed this to just
(gdb) print slice
$80 = [3]
This patch restores the previous behavior.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30330
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31517
While examining the Ada parser globals with 'nm', I noticed that the
lexer's "attributes" array should be const. This change moves it into
read-only storage.
This patch moves the "temp_parse_space" global into ada_parse_state.
It is also renamed to remove the redundant "parse". Finally, it is
changed to an auto_obstack to avoid the need for any manual
management.
This patch introduces the ada_parse_state class and the ada_parser
global. It also changes find_completion_bounds to be a method of this
new type.
Note that find_completion_bounds never used its parameter; and because
it is generally fine to use the 'pstate' global throughout the parser,
this patch removes the parameter entirely.
Ada 2022 includes iterated assignment for array initialization. This
patch implements a subset of this for gdb. In particular, only arrays
with integer index types really work -- currently there's no decent
way to get the index type in EVAL_AVOID_SIDE_EFFECTS mode during
parsing. Fixing this probably requires the Ada parser to take a
somewhat more sophisticated approach to type resolution; and while
this would help fix another bug in this area, this patch is already
useful without it.
This patch is a refactoring to add a new aggregate_assigner type.
This type is passed to Ada aggregate assignment operations in place of
passing a number of separate arguments. This new approach makes it
simpler to change some aspects of aggregate assignment behavior.
