Hi!

On Mon, 17 Dec 2018 13:41:25 -0800, John Baldwin <jhb@FreeBSD.org> wrote:
> 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> 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).

(We probably wouldn't be able to do that: necessary to work around some
compiler bug, I've seen a number of commits that changed "new-style C++
for iterators" away from 'for (struct thread_info *ti : [something])' to
just 'thread_info *ti' (without 'class' or 'struct').)

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

Right.  I have now pushed to master the attached commit
cabb5f067daa9227bf0323cbf64c6065d6e4796f "[gdb, hurd] Work around
conflict between Mach's 'thread_info' function, and GDB's 'thread_info'
class".


Grüße
 Thomas