Re: [PATCH] Please define thread_info as struct thread_info (and other stuff)

[John Baldwin <jhb@FreeBSD.org>]

On 12/17/18 12:51 PM, Svante Signell wrote:
> On Sun, 2018-12-16 at 16:10 -0700, Tom Tromey wrote:
>>>>>>> "Svante" == Svante Signell <svante.signell@gmail.com> writes:
>> Svante> Another issue is to compile C-code (and C++-code) in *.c files.
>> Svante> Please rename these to *.cpp (and eventually the header files to
>> *.hpp)! As it is now it is very confusing.
>>
>> I think this was discussed When we made this switch, and the conclusion
>> was that a mass rename would be worse.
> 
> Do you really need to compile all files with a C++ compiler? Pure C-code could
> still be compiled with a C compiler.

GDB isn't written in C anymore.  target_ops is a class with virtual methods,
the use of gdb::unique_ptr<> (basically std::unique_ptr<>) is rather
ubiquitous now, etc.  In fact, I think we even require C++11 and not just
C++03.

>> Svante> Finally, I've found the problem (but no workaround yet): thread_info
>> is an RPC on GNU/Hurd, and including mach.h in gdb/config/i386/nm-
>> i386gnu.h:#include <mach.h> further includes <mach/mach_interface.h> which has
>> the conflicting name Svante> of that RPC: kern_return_t thread_info
>>
>> Typical answers for this kind of thing are either to segregate the use
>> of the system header somehow, or maybe namespacing or some other kind of
>> renaming.  I haven't looked into the details much in this case I'm
>> afraid.
> 
> As I see it you need to:
> 
> 1) Apply the patches submitted earlier in this thread using struct thread_info
> consistently everywhere (simplest).
> 2) Rename all usage of the struct thread_info to something else e.g. struct
> gdb_thread_info (not future-proof though).
> 3) Create a gdb namespace for all your code to avoid conflicts.
> 4) Segregate the use of system header files as you write above. Dunno how to do
> that though, but some of you should.

Normally code for native targets do 4).  I've had to be careful about which
includes I use in native FreeBSD targets to avoid namespace collisions, etc.
3) might not be a terrible idea eventually, but you'd have to make it explict
and avoid using 'using namespace gdb' for it to actually be useful.

-- 
John Baldwin