public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Rainer Orth <ro@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] Fix various procfs.c compilation errors Date: Thu, 17 Nov 2022 09:55:56 +0000 (GMT) [thread overview] Message-ID: <20221117095556.B1FC3395A407@sourceware.org> (raw) 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> Diff: --- gdb/procfs.c | 24 +++++++++--------------- 1 file changed, 9 insertions(+), 15 deletions(-) diff --git a/gdb/procfs.c b/gdb/procfs.c index c5715627f6f..141db3dd793 100644 --- a/gdb/procfs.c +++ b/gdb/procfs.c @@ -141,8 +141,8 @@ public: bool info_proc (const char *, enum info_proc_what) override; #if PR_MODEL_NATIVE == PR_MODEL_LP64 - int auxv_parse (gdb_byte **readptr, - gdb_byte *endptr, CORE_ADDR *typep, CORE_ADDR *valp) + int auxv_parse (const gdb_byte **readptr, + const gdb_byte *endptr, CORE_ADDR *typep, CORE_ADDR *valp) override; #endif @@ -169,11 +169,12 @@ static procfs_target the_procfs_target; is presented in 64-bit format. We need to provide a custom parser to handle that. */ int -procfs_target::auxv_parse (gdb_byte **readptr, - gdb_byte *endptr, CORE_ADDR *typep, CORE_ADDR *valp) +procfs_target::auxv_parse (const gdb_byte **readptr, + const gdb_byte *endptr, CORE_ADDR *typep, + CORE_ADDR *valp) { enum bfd_endian byte_order = gdbarch_byte_order (target_gdbarch ()); - gdb_byte *ptr = *readptr; + const gdb_byte *ptr = *readptr; if (endptr == ptr) return 0; @@ -559,15 +560,7 @@ enum { NOKILL, KILL }; static void dead_procinfo (procinfo *pi, const char *msg, int kill_p) { - char procfile[80]; - - if (pi->pathname) - print_sys_errmsg (pi->pathname, errno); - else - { - xsnprintf (procfile, sizeof (procfile), "process %d", pi->pid); - print_sys_errmsg (procfile, errno); - } + print_sys_errmsg (pi->pathname, errno); if (kill_p == KILL) kill (pi->pid, SIGKILL); @@ -2813,7 +2806,7 @@ procfs_target::create_inferior (const char *exec_file, len = p1 - p; else len = strlen (p); - strncpy (tryname, p, len); + memcpy (tryname, p, len); tryname[len] = '\0'; strcat (tryname, "/"); strcat (tryname, shell_file); @@ -3170,6 +3163,7 @@ find_memory_regions_callback (struct prmap *map, (map->pr_mflags & MA_WRITE) != 0, (map->pr_mflags & MA_EXEC) != 0, 1, /* MODIFIED is unknown, pass it as true. */ + false, data); }
reply other threads:[~2022-11-17 9:55 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20221117095556.B1FC3395A407@sourceware.org \ --to=ro@sourceware.org \ --cc=gdb-cvs@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: linkBe 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).