public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug build/29791] [13 regression] Many gdbsupport files don't compile on Solaris
Date: Thu, 17 Nov 2022 09:55:59 +0000	[thread overview]
Message-ID: <bug-29791-4717-XF99MRf7BZ@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-29791-4717@http.sourceware.org/bugzilla/>

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.

  parent reply	other threads:[~2022-11-17  9:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16 14:41 [Bug build/29791] New: " ro at gcc dot gnu.org
2022-11-16 14:42 ` [Bug build/29791] " ro at gcc dot gnu.org
2022-11-16 14:43 ` ro at gcc dot gnu.org
2022-11-16 14:44 ` ro at gcc dot gnu.org
2022-11-16 19:21 ` tromey at sourceware dot org
2022-11-17  9:55 ` cvs-commit at gcc dot gnu.org [this message]
2022-11-18 12:50 ` ro at gcc dot gnu.org
2022-11-18 13:10 ` ro at gcc dot gnu.org
2022-11-20 14:15 ` ro at gcc dot gnu.org
2022-11-26 14:09 ` brobecker at gnat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-29791-4717-XF99MRf7BZ@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).