aboutsummaryrefslogtreecommitdiff
path: root/gdb/c-lang.c
diff options
context:
space:
mode:
authorTom Tromey <tom@tromey.com>2021-09-06 10:20:02 -0600
committerTom Tromey <tom@tromey.com>2022-04-12 09:31:16 -0600
commitda6322977928bc23b0d6a3a88af8c935fb334f3e (patch)
tree3278ff13c47423791dee79084776db84a57afbed /gdb/c-lang.c
parent68a85bc267a7ecbcbe3a465bd80aac60b3b70d5a (diff)
downloadgdb-da6322977928bc23b0d6a3a88af8c935fb334f3e.zip
gdb-da6322977928bc23b0d6a3a88af8c935fb334f3e.tar.gz
gdb-da6322977928bc23b0d6a3a88af8c935fb334f3e.tar.bz2
Introduce thread-safe handling for complaints
This introduces a new class that can be used to make the "complaint" code thread-safe. Instantiating the class installs a new handler that collects complaints, and then prints them all when the object is destroyed. This approach requires some locks. I couldn't think of a better way to handle this, though, because the I/O system is not thread-safe. It seemed to me that only GDB developers are likely to enable complaints, and because the complaint macro handle this case already (before any locks are required), I reasoned that any performance degradation that would result here would be fine. As an aside about complaints -- are they useful at all? I just ignore them, myself, since mostly they seem to indicate compiler problems that can't be solved in the GDB world anyway. I'd personally prefer them to be in a separate tool, like a hypothetical 'dwarflint'.
Diffstat (limited to 'gdb/c-lang.c')
0 files changed, 0 insertions, 0 deletions