aboutsummaryrefslogtreecommitdiff
path: root/gdb/or1k-linux-tdep.c
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-12-22 11:48:54 +0000
committerAndrew Burgess <aburgess@redhat.com>2024-01-04 09:24:18 +0000
commitc9f1e0dfc8f02a7772aa383cc305d9049075d1d8 (patch)
tree2a18e0cbf9bd23a669f6e5ba5c4280d44f537b9f /gdb/or1k-linux-tdep.c
parent06bfdc6e5ee0745877ef941f50f680d342b5c585 (diff)
downloadgdb-c9f1e0dfc8f02a7772aa383cc305d9049075d1d8.zip
gdb-c9f1e0dfc8f02a7772aa383cc305d9049075d1d8.tar.gz
gdb-c9f1e0dfc8f02a7772aa383cc305d9049075d1d8.tar.bz2
gdb: don't try to style content in error calls
While working on a later commit in this series I realised that the error() function doesn't support output styling. Due to the way that output from error() calls is passed around within the exception object and often combined with other output, it's not immediately obvious to me if we should be trying to support styling in this context or not. On inspection, I found one place in GDB where we apparently try to apply styling within the error() output (in procfs.c). I suspect this error() call might not be tested. Rather than try to implement styling in the error() output, right now I'm proposing to just remove the attempt to style error() output. This doesn't mean that someone shouldn't add error() styling in the future, but right now, I'm not planning to do that, I just wanted to fix this in passing. Approved-By: John Baldwin <jhb@FreeBSD.org>
Diffstat (limited to 'gdb/or1k-linux-tdep.c')
0 files changed, 0 insertions, 0 deletions