This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: Building GDB under GLIBC 2.8
> Okay, I think this revision makes the changes people suggested.
One of the things that I was wondering about is the report about
numerous core files found after running the testsuite. Was this
addressed by this new version?
> commit 01ff08caa6977858da014630578f708b86f84803
> Author: Jim Blandy <jimb@red-bean.com>
> Date: Fri Dec 12 17:47:01 2008 -0800
>
> gdb
> Check return values of functions declared with warn_unused_result
> attribute in GLIBC 2.8.
> * cli/cli-cmds.c (pwd_command): Check return value from getcwd.
> * inflow.c (check_syscall): New function.
> (new_tty): Use check_syscall to check return values from open and dup.
> * linux-nat.c (linux_nat_info_proc_cmd): Check return value from fgets.
> * main.c (captured_main): Call cwd after setting up gdb_stderr;
> check for errors from getcwd.
> * mi/mi-cmd-env.c (mi_cmd_env_pwd): Check return value from getcwd.
> * ui-file.c (stdio_file_write): Ignore return value from fwrite.
> (stdio_file_fputs): Same.
> * utils.c (internal_vproblem): abort if last-ditch error message
> write fails.
Looks OK to me. I'm a little bit pained by seeing us forced to check
return values in cases where we really don't care, but if this is
the way things are going to be in glibc from now on. Were the glibc
developers contacted and do we know what they said? I'm wondering
if these new attributes are a done-deal or whether there are
re-considering...
> --- a/gdb/linux-nat.c
> +++ b/gdb/linux-nat.c
> @@ -3666,8 +3666,10 @@ linux_nat_info_proc_cmd (char *args, int from_tty)
> if ((procfile = fopen (fname1, "r")) != NULL)
> {
> struct cleanup *cleanup = make_cleanup_fclose (procfile);
> - fgets (buffer, sizeof (buffer), procfile);
> - printf_filtered ("cmdline = '%s'\n", buffer);
> + if (fgets (buffer, sizeof (buffer), procfile))
> + printf_filtered ("cmdline = '%s'\n", buffer);
> + else
> + warning (_("unable to read '/proc/%lld/cmdline'"), pid);
I suggest taking advantage of fname1 in the call to warning, rather than
duplicating the actual path.
--
Joel