Manual contradicts itself regarding second command line argument

Manual contradicts itself regarding second command line argument

[Mark H Weaver]

Section 2.1 of "Debugging with GDB" states:

       gdb PROGRAM 1234

  would attach GDB to process '1234' (unless you also have a file named
  '1234'; GDB does check for a core file first).

and section 2.1.1 states:

  [...] If the second argument begins with a decimal digit, GDB will
  first attempt to attach to it as a process, and if that fails, attempt
  to open it as a corefile.

They contradict each other regarding the order of the checks.

       Mark

[PATCH] doc: fix false claim about second argument to gdb (was: Manual contradicts itself regarding second command line argument)

[Simon Marchi]

On 2019-06-17 8:04 p.m., Mark H Weaver wrote:
> Section 2.1 of "Debugging with GDB" states:
> 
>        gdb PROGRAM 1234
> 
>   would attach GDB to process '1234' (unless you also have a file named
>   '1234'; GDB does check for a core file first).
> 
> and section 2.1.1 states:
> 
>   [...] If the second argument begins with a decimal digit, GDB will
>   first attempt to attach to it as a process, and if that fails, attempt
>   to open it as a corefile.
> 
> They contradict each other regarding the order of the checks.
> 
>        Mark
> 

Thanks Mark.

Here's a patch below that would fix this.

From d24c4ad2eac8c76b021fa304323c3f13b12e0d06 Mon Sep 17 00:00:00 2001
From: Simon Marchi <simon.marchi@efficios.com>
Date: Tue, 18 Jun 2019 10:35:45 -0400
Subject: [PATCH] doc: fix false claim about second argument to gdb

Section "Invoking GDB" of the manual states that if you try to launch
gdb with:

  gdb program 1234

it will try to attach to the process with id 1234, unless there is a
file named 1234 in the current working directory, in which case it will
try to open that file as a core.  In fact, when the second argument
starts with a digit, GDB tries to attach to process 1234 first, before
trying to open file 1234 as a core.  So that last remark is not true and
therefore this patch removes it.

The same remark is present in the man page, so it is removed there too.

Section "Choosing Files" correctly states:

  If the second argument begins with a decimal digit, GDB will first
  attempt to attach to it as a process, and if that fails, attempt to
  open it as a corefile.

so it is unchanged.

Finally, the man page has an additional detail compared to section
"Invoking GDB", regarding the use of the -p switch, so I added the same
detail to the "Invoking GDB" section.

gdb/doc/ChangeLog:

	* gdb.texinfo (Invoking GDB): Remove sentence about how GDB
	deals with a file that has the same name as the specified pid to
	attach to.  Add example using -p option.
	(gdb man): Remove same sentence as in previous item.
---
 gdb/doc/gdb.texinfo | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 9a0320e5d8f8..b787280b8870 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -874,16 +874,17 @@ specified:
 @value{GDBP} @var{program} @var{core}
 @end smallexample

-You can, instead, specify a process ID as a second argument, if you want
-to debug a running process:
+You can, instead, specify a process ID as a second argument or using option
+@code{-p}, if you want to debug a running process:

 @smallexample
 @value{GDBP} @var{program} 1234
+@value{GDBP} -p 1234
 @end smallexample

 @noindent
-would attach @value{GDBN} to process @code{1234} (unless you also have a file
-named @file{1234}; @value{GDBN} does check for a core file first).
+would attach @value{GDBN} to process @code{1234}.  With option @option{-p} you
+can omit the @var{program} filename.

 Taking advantage of the second command-line argument requires a fairly
 complete operating system; when you use @value{GDBN} as a remote
@@ -44863,8 +44864,8 @@ You can also start with both an executable program and a core file specified:
 gdb program core
 @end smallexample

-You can, instead, specify a process ID as a second argument, if you want
-to debug a running process:
+You can, instead, specify a process ID as a second argument or using option
+@code{-p}, if you want to debug a running process:

 @smallexample
 gdb program 1234
@@ -44872,9 +44873,8 @@ gdb -p 1234
 @end smallexample

 @noindent
-would attach @value{GDBN} to process @code{1234} (unless you also have a file
-named @file{1234}; @value{GDBN} does check for a core file first).
-With option @option{-p} you can omit the @var{program} filename.
+would attach @value{GDBN} to process @code{1234}.  With option @option{-p} you
+can omit the @var{program} filename.

 Here are some of the most frequently needed @value{GDBN} commands:

-- 
2.21.0

Re: [PATCH] doc: fix false claim about second argument to gdb (was: Manual contradicts itself regarding second command line argument)

[Eli Zaretskii]

> From: Simon Marchi <simark@simark.ca>
> Date: Tue, 18 Jun 2019 10:51:03 -0400
> 
> -You can, instead, specify a process ID as a second argument, if you want
> -to debug a running process:
> +You can, instead, specify a process ID as a second argument or using option
> +@code{-p}, if you want to debug a running process:

"specify ... or using ..." is incorrect English.  I guess you meant
"use"?

No other comments, thanks.  (I didn't look at the code to see if the
description is factually correct.)

Re: [PATCH] doc: fix false claim about second argument to gdb

[Simon Marchi]

On 2019-06-18 12:14 p.m., Eli Zaretskii wrote:
>> From: Simon Marchi <simark@simark.ca>
>> Date: Tue, 18 Jun 2019 10:51:03 -0400
>>
>> -You can, instead, specify a process ID as a second argument, if you want
>> -to debug a running process:
>> +You can, instead, specify a process ID as a second argument or using option
>> +@code{-p}, if you want to debug a running process:
> 
> "specify ... or using ..." is incorrect English.  I guess you meant
> "use"?

Oh, that's right.  Changed it to "use".

> No other comments, thanks.  (I didn't look at the code to see if the
> description is factually correct.)

I didn't check the code either, but tried various combinations and observed this behavior.

I pushed the patch with the error above fixed, thanks.

Simon