Re: [PATCH 1/3] Make several more BFD globals thread-local

[Tom Tromey <tom@tromey.com>]

>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:

Tom> What I meant when I wrote the above is that basically there are two sets
Tom> of globals to consider in this patch: the ones related to error emission
Tom> (_bfd_error_internal and error_handler_bfd), and then the other ones
Tom> related to the caching error message code (per_xvec_warn,
Tom> in_check_format).

Tom> I thought that making the latter ones thread-local felt hackish, because
Tom> they could somewhat easily be attributes of a BFD and not globals at
Tom> all.

Tom> I took a stab at some of this tonight and discovered that since
Tom> in_check_format is only used by the error-reporting code, it can be
Tom> combined with the other flag.

Tom> I've appended a rough draft of this.

Tom> I haven't tackled the xvec stuff yet.

I looked into this problem this evening and I found out that the
per-xvec errors are also only used from inside bfd_check_format_matches.
A (thread-local) global would still be needed, because warnings aren't
emitted "per-BFD" -- but it could just replace error_handler_bfd,
leaving just a single global.

I haven't implemented this but I plan to try it soon.  This is one of
the issues blocking GDB 15.

Tom> Also I think it'd be good if print_warnmsg re-emitted the errors using
Tom> _bfd_error_handler.  This would let gdb print them the way it likes.
Tom> However... that's a change to semantics so I don't know if that's OK or
Tom> whether another error emitter is required.  I guess I don't really know
Tom> how to provoke one of these messages and when they would matter.  Like,
Tom> I see that ldmain.c installs an error handler -- is it intentional that
Tom> this be bypassed by errors occurring in bfd_check_format_matches?

I'd appreciate some insight into this.

thanks,
Tom