[Bug build/29791] New: [13 regression] Many gdbsupport files don't compile on Solaris

[Bug build/29791] New: [13 regression] Many gdbsupport files don't compile on Solaris

[ro at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29791

            Bug ID: 29791
           Summary: [13 regression] Many gdbsupport files don't compile on
                    Solaris
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: build
          Assignee: unassigned at sourceware dot org
          Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
              Host: *-*-solaris2.11
            Target: *-*-solaris2.11
             Build: *-*-solaris2.11

When trying to build current trunk on Solaris 11.4 (both SPARC and x86) with
the bundled GCC 12.2.0, a large part of gdbsupport failed to compile like this:

$ g++  -DHAVE_CONFIG_H -I. -I/vol/src/gnu/gdb/hg/master/dist/gdbsupport 
-I/vol/src/gnu/gdb/hg/master/dist/gdbsupport/../include
-I/vol/src/gnu/gdb/hg/master/dist/gdbsupport/../gdb -I../gnulib/import
-I/vol/src/gnu/gdb/hg/master/dist/gdbsupport/../gnulib/import -I..
-I/vol/src/gnu/gdb/hg/master/dist/gdbsupport/..  -I../bfd
-I/vol/src/gnu/gdb/hg/master/dist/gdbsupport/../bfd   -Wall -Wpointer-arith
-Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch
-Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter
-Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized
-Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=3
-Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor
-Wredundant-move -Wmissing-declarations -Wstrict-null-sentinel
-Wno-unknown-pragmas -Wno-deprecated-declarations -Werror -g -O2     -MT ptid.o
-MD -MP -MF .deps/ptid.Tpo -c -o ptid.o
/vol/src/gnu/gdb/hg/master/dist/gdbsupport/ptid.cc
In file included from /usr/include/sys/time.h:448,
                 from ../gnulib/import/sys/time.h:39,
                 from /usr/include/sys/select.h:27,
                 from ../gnulib/import/sys/select.h:36,
                 from /usr/include/sys/types.h:665,
                 from ../gnulib/import/sys/types.h:39,
                 from ../gnulib/import/stdio.h:58,
                 from
/vol/src/gnu/gdb/hg/master/dist/gdbsupport/common-defs.h:86,
                 from /vol/src/gnu/gdb/hg/master/dist/gdbsupport/ptid.cc:20:
../gnulib/config.h:1693:72: error: ‘malloc’ attribute argument 1 is ambiguous
 1693 | # define _GL_ATTRIBUTE_DEALLOC(f, i) __attribute__ ((__malloc__ (f,
i)))
      |                                                                       
^
../gnulib/config.h:1693:72: note: use a cast to the expected type to
disambiguate
../gnulib/config.h:1693:72: error: ‘malloc’ attribute argument 1 is ambiguous
 1693 | # define _GL_ATTRIBUTE_DEALLOC(f, i) __attribute__ ((__malloc__ (f,
i)))
      |                                                                       
^
../gnulib/config.h:1693:72: note: use a cast to the expected type to
disambiguate
../gnulib/config.h:1693:72: error: ‘malloc’ attribute argument 1 is ambiguous
 1693 | # define _GL_ATTRIBUTE_DEALLOC(f, i) __attribute__ ((__malloc__ (f,
i)))
      |                                                                       
^
../gnulib/config.h:1693:72: note: use a cast to the expected type to
disambiguate
../gnulib/config.h:1693:72: error: ‘malloc’ attribute argument 1 is ambiguous
 1693 | # define _GL_ATTRIBUTE_DEALLOC(f, i) __attribute__ ((__malloc__ (f,
i)))
      |                                                                       
^
../gnulib/config.h:1693:72: note: use a cast to the expected type to
disambiguate

TBH, I don't have the slightest idea what this is supposed to mean, let alone
how to fix it.

It can be reproduced with the attached ptid.ii as

$ g++ -Wall -O2 -c -o ptid.o ptid.ii

To get further along, I'm currently using the attached hack to disable
_GL_ATTRIBUTE_DEALLOC on Solaris.
For the time being, I've

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29791] [13 regression] Many gdbsupport files don't compile on Solaris

[ro at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29791

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29791] [13 regression] Many gdbsupport files don't compile on Solaris

[ro at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29791

--- Comment #1 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 14456
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14456&action=edit
Preprocessed ptid.cc

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29791] [13 regression] Many gdbsupport files don't compile on Solaris

[ro at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29791

--- Comment #2 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 14457
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14457&action=edit
Workaround patch

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29791] [13 regression] Many gdbsupport files don't compile on Solaris

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29791

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
I found this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101747
which points out a problem with the 2-argument form of
the malloc attribute.

Unfortunately the error messages here don't tell us enough to know
where the ambiguous use occurs.  They just refer back to the macro
itself -- but we want the spot where it is invoked.  Normally GCC
shows this.

I also don't know the correct fix.  The opacity here is one of the
issues with using gnulib, IMO.  Maybe reaching out to them is the
best thing to do.  Meanwhile, especially just before the GDB 13
release, I'm reasonably fine with a workaround like the one you have.

Our gnulib import has a way to automate application of a patch
when doing a new import.  See gnulib/update-gnulib.sh and
gnulib/patches/.  I guess you should do something along those
lines.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29791] [13 regression] Many gdbsupport files don't compile on Solaris

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29791

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Rainer Orth <ro@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f4ad82b3bcc4ae2cecba00177561ddfad49ccef2

commit f4ad82b3bcc4ae2cecba00177561ddfad49ccef2
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date:   Thu Nov 17 10:55:25 2022 +0100

    Fix various procfs.c compilation errors

    procfs.c has accumulated several compilation errors lately (some of them
    new with GCC 12), which are fixed by this patch:

    * auxv_parse gets:

    /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:144:7: error: int
    procfs_target::auxv_parse(gdb_byte**, gdb_byte*, CORE_ADDR*, CORE_ADDR*)
    marked override, but does not override
      144 |   int auxv_parse (gdb_byte **readptr,
          |       ^~~~~~~~~~

      Obviouly, procfs.c was missed in the auxv_parse constification.

    * dead_procinfo has:

    /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In function void
    dead_procinfo(procinfo*, const char*, int):
    /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:563:11: warning: the address
    of procinfo::pathname will never be NULL [-Waddress]
      563 |   if (pi->pathname)
          |       ~~~~^~~~~~~~
    /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:238:8: note:
    procinfo::pathname declared here
      238 |   char pathname[MAX_PROC_NAME_SIZE];    /* Pathname to /proc entry
*/
          |        ^~~~~~~~

      The warning is correct, so the code can lose support for the NULL
      pathname case.

    * create_inferior has this ugly warning:

    /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function virtual
void procfs_target::create_inferior(const char*, const std::string&, char**,
int):
    /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:2815:19: warning: char*
std::strncpy(char*, const char*, size_t) output truncated before terminating
nul copying as many bytes from a string as its length [-Wstringop-truncation]
     2815 |           strncpy (tryname, p, len);
          |           ~~~~~~~~^~~~~~~~~~~~~~~~~
    /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:2814:26: note: length computed
here
     2814 |             len = strlen (p);
          |                   ~~~~~~~^~~

      It seems that this is another case of GCC PR middle-end/88059, which
      Martin Sebor refuses to fix.  So I'm using the hack suggested in the
      PR to use memcpy instead of strncpy.

    * find_memory_regions_callback fails with

    /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In function int
find_memory_regions_callback(prmap*, find_memory_region_ftype, void*):
    /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3167:18: error: too few
arguments to function
     3167 |   return (*func) ((CORE_ADDR) map->pr_vaddr,
          |          ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
     3168 |                   map->pr_size,
          |                   ~~~~~~~~~~~~~
     3169 |                   (map->pr_mflags & MA_READ) != 0,
          |                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     3170 |                   (map->pr_mflags & MA_WRITE) != 0,
          |                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     3171 |                   (map->pr_mflags & MA_EXEC) != 0,
          |                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     3172 |                   1, /* MODIFIED is unknown, pass it as true.  */
          |                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     3173 |                   data);
          |                   ~~~~~

      Again, procfs.c was overlooked when adding the new memory_tagged arg.
      Unfortunately, it wasn't even documented in gdb/defs.h when it was
      added in

    commit 68cffbbd4406b4efe1aa6e18460b1d7ca02549f1
    Author: Luis Machado <luis.machado@arm.com>
    Date:   Thu Mar 31 11:42:35 2022 +0100

        [AArch64] MTE corefile support

    With those changes, procfs.c compiles again.  Together with the hack
    from the Solaris gdbsupport breakage reported in PR build/29791, I was
    able to build and test gdb on both amd64-pc-solaris2.11 and
    sparcv9-sun-solaris2.11.

    Approved-By: Simon Marchi <simon.marchi@efficios.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29791] [13 regression] Many gdbsupport files don't compile on Solaris

[ro at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29791

--- Comment #5 from Rainer Orth <ro at gcc dot gnu.org> ---
(In reply to Tom Tromey from comment #3)
> I found this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101747
> which points out a problem with the 2-argument form of
> the malloc attribute.

I'd found this myself, but forgotten about it.  I've meanwhile reported the
current failure in that PR: let's see what we get from that.

> Unfortunately the error messages here don't tell us enough to know
> where the ambiguous use occurs.  They just refer back to the macro
> itself -- but we want the spot where it is invoked.  Normally GCC
> shows this.

Indeed: that's why I couldn't really make sense of the error, and failed to
produce a reduced testcase.

> I also don't know the correct fix.  The opacity here is one of the
> issues with using gnulib, IMO.  Maybe reaching out to them is the
> best thing to do.  Meanwhile, especially just before the GDB 13
> release, I'm reasonably fine with a workaround like the one you have.

My current feeling is to wait with a gnulib bug report until I hear from the
GCC side: otherwise, there's probably not much what they can do about the
problem.

> Our gnulib import has a way to automate application of a patch
> when doing a new import.  See gnulib/update-gnulib.sh and
> gnulib/patches/.  I guess you should do something along those
> lines.

Thanks, that got me started.  I've a patch ready along those lines that I will
post shortly.

Thanks.
  Rainer

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29791] [13 regression] Many gdbsupport files don't compile on Solaris

[ro at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29791

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |ro at gcc dot gnu.org
                URL|                            |https://sourceware.org/pipe
                   |                            |rmail/gdb-patches/2022-Nove
                   |                            |mber/193950.html

--- Comment #6 from Rainer Orth <ro at gcc dot gnu.org> ---
Proposed patch posted.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29791] [13 regression] Many gdbsupport files don't compile on Solaris

[ro at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29791

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #7 from Rainer Orth <ro at gcc dot gnu.org> ---
The patch has now been committed, although bugzilla somehow didn't pick that
up.

However, I'd like to keep the PR open for a bit in case I get an analysis of
what's wrong (and a real fix) in the GCC PR.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29791] [13 regression] Many gdbsupport files don't compile on Solaris

[brobecker at gnat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29791

Joel Brobecker <brobecker at gnat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.1                        |---
                 CC|                            |brobecker at gnat dot com

--- Comment #8 from Joel Brobecker <brobecker at gnat dot com> ---
Since the GDB side of things is now in order and we're keeping this PR open
pending some other analysis, I am removing the target milestone, so as to drop
this PR from the release dashboard.

Another option if you prefer, Rainer, would be to mark this PR as done with
target milestone 13.1, and open a separate PR for the GCC side of things. The
former allows for slightly more structured information, but since I don't think
any release is impacted, I don't see this as being critical.

-- 
You are receiving this mail because:
You are on the CC list for the bug.