[PATCH v2] gdb/hurd: pass memory_tagged as false to find_memory_region_ftype

[Enze Li]

On Mon, 2022-07-25 at 08:55 -0700, John Baldwin wrote:
> On 7/25/22 12:39 AM, Luis Machado wrote:
> > Hi!
> > 
> > On 7/24/22 04:40, Enze Li wrote:
> > > I tried building GDB on GNU/Hurd, and ran into this error:
> > > 
> > >     CXX    gnu-nat.o
> > > gnu-nat.c: In member function ‘virtual int
> > > gnu_nat_target::find_memory_regions(find_memory_region_ftype,
> > > void*)’:
> > > gnu-nat.c:2620:21: error: too few arguments to function
> > >    2620 |             (*func) (last_region_address,
> > >         |             ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
> > >    2621 |                      last_region_end -
> > > last_region_address,
> > >         |                     
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >    2622 |                      last_protection & VM_PROT_READ,
> > >         |                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >    2623 |                      last_protection & VM_PROT_WRITE,
> > >         |                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >    2624 |                      last_protection & VM_PROT_EXECUTE,
> > >         |                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >    2625 |                      1, /* MODIFIED is unknown, pass it
> > > as true.  */
> > >         |                     
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >    2626 |                      data);
> > >         |                      ~~~~~
> > > gnu-nat.c:2635:13: error: too few arguments to function
> > >    2635 |     (*func) (last_region_address, last_region_end -
> > > last_region_address,
> > >         |    
> > > ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > ~~~
> > >    2636 |              last_protection & VM_PROT_READ,
> > >         |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >    2637 |              last_protection & VM_PROT_WRITE,
> > >         |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >    2638 |              last_protection & VM_PROT_EXECUTE,
> > >         |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >    2639 |              1, /* MODIFIED is unknown, pass it as
> > > true.  */
> > >         |             
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >    2640 |              data);
> > >         |              ~~~~~
> > > make[2]: *** [Makefile:1926: gnu-nat.o] Error 1
> > > 
> > > This is because in this commit:
> > > 
> > >     commit 68cffbbd4406b4efe1aa6e18460b1d7ca02549f1
> > >     Date:   Thu Mar 31 11:42:35 2022 +0100
> > > 
> > >         [AArch64] MTE corefile support
> > > 
> > > Added a new argument to find_memory_region_ftype, but did not
> > > pass it to
> > > the function in gnu-nat.c.  Fix this by passing memory_tagged as
> > > false.
> > > 
> > > As Luis pointed out, similar bugs may also appear on FreeBSD and
> > > NetBSD,
> > > and I have reproduced them on both systems.  This patch fixes
> > > them
> > > incidentally.
> > > 
> > > Tested by rebuilding on GNU/Hurd, FreeBSD/amd64 and NetBSD/amd64.
> > > ---
> > >    gdb/fbsd-nat.c   | 2 +-
> > >    gdb/gnu-nat.c    | 2 ++
> > >    gdb/netbsd-nat.c | 2 +-
> > >    3 files changed, 4 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/gdb/fbsd-nat.c b/gdb/fbsd-nat.c
> > > index 398f1c18b33..a4ca4a53415 100644
> > > --- a/gdb/fbsd-nat.c
> > > +++ b/gdb/fbsd-nat.c
> > > @@ -125,7 +125,7 @@ fbsd_nat_target::find_memory_regions
> > > (find_memory_region_ftype func,
> > >          Pass MODIFIED as true, we do not know the real
> > > modification state.  */
> > >          func (kve->kve_start, size, kve->kve_protection &
> > > KVME_PROT_READ,
> > >             kve->kve_protection & KVME_PROT_WRITE,
> > > -           kve->kve_protection & KVME_PROT_EXEC, 1, data);
> > > +           kve->kve_protection & KVME_PROT_EXEC, 1, false,
> > > data);
> > >        }
> > >      return 0;
> > >    }
> > > diff --git a/gdb/gnu-nat.c b/gdb/gnu-nat.c
> > > index 72314824278..5dd4d148c76 100644
> > > --- a/gdb/gnu-nat.c
> > > +++ b/gdb/gnu-nat.c
> > > @@ -2623,6 +2623,7 @@ gnu_nat_target::find_memory_regions
> > > (find_memory_region_ftype func,
> > >                      last_protection & VM_PROT_WRITE,
> > >                      last_protection & VM_PROT_EXECUTE,
> > >                      1, /* MODIFIED is unknown, pass it as true. 
> > > */
> > > +                    false, /* No memory tags in the object
> > > file.  */
> > >                      data);
> > >           last_region_address = region_address;
> > >           last_region_end = region_address += region_length;
> > > @@ -2637,6 +2638,7 @@ gnu_nat_target::find_memory_regions
> > > (find_memory_region_ftype func,
> > >              last_protection & VM_PROT_WRITE,
> > >              last_protection & VM_PROT_EXECUTE,
> > >              1, /* MODIFIED is unknown, pass it as true.  */
> > > +            false, /* No memory tags in the object file.  */
> > >              data);
> > >    
> > >      return 0;
> > > diff --git a/gdb/netbsd-nat.c b/gdb/netbsd-nat.c
> > > index c45df391afc..d3bf83d35f5 100644
> > > --- a/gdb/netbsd-nat.c
> > > +++ b/gdb/netbsd-nat.c
> > > @@ -259,7 +259,7 @@ nbsd_nat_target::find_memory_regions
> > > (find_memory_region_ftype func,
> > >          Pass MODIFIED as true, we do not know the real
> > > modification state.  */
> > >          func (kve->kve_start, size, kve->kve_protection &
> > > KVME_PROT_READ,
> > >             kve->kve_protection & KVME_PROT_WRITE,
> > > -           kve->kve_protection & KVME_PROT_EXEC, 1, data);
> > > +           kve->kve_protection & KVME_PROT_EXEC, 1, false,
> > > data);
> > >        }
> > >      return 0;
> > >    }
> > 
> > The above LGTM. Thanks again for getting these files fixed. I think
> > this one can go in as it is
> > fairly obvious and addresses broken builds for hurd, fbsd and
> > netbsd
> 
> Agreed, and the BSD bits all look good to me.

Hi John, Luis,

Thank you for the review.

> 
> Enze, do you have push access or do you need someone to push this
> (and the
> other netbsd build fix) for you?
> 

Yeah, I have.  I'm checking this in now.

Thanks,
Enze