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

[Svante Signell]

On Sun, 2018-12-16 at 16:10 -0700, Tom Tromey wrote:
> > > > > > "Svante" == Svante Signell <svante.signell@gmail.com> writes:
> > > Try adding a forward declaration of struct thead_info.  Note that
> > > config/i386/nm-i386gnu.h includes "regcache.h", making it unique among
> > > the nm.h files.
> 
> Svante> From what I've learned forward declarations is bad coding, an should
> be avoided
> Svante> as much as possible. Right or wrong?
> 
> Opinions vary -- I think the Google style has a rule against it? -- but
> gdb generally does not avoid it.
> 
> Svante> Furthermore, not defining thread_info as struct everywhere is in my
> opinion very
> Svante> lazy coding.
> 
> I disagree here, C++ provides the typedef, there's nothing really wrong
> with using it.

Well, the basis is C-code, where that is a requirement.

> 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.
 
> 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.

Thanks!