Re: [PATCH] "$ gdb PROGRAM" vs "(gdb) file PROGRAM" difference; warn on failure to remove breakpoint.

[Pedro Alves <palves@redhat.com>]

On 06/12/2014 04:47 AM, Yao Qi wrote:
> On 06/09/2014 10:22 PM, Pedro Alves wrote:
>> And, likewise, "file" with no arguments only started turning
>> breakpoints set in the main executable to "<pending>" with the
>> remote-symbol-file patch (63644780).  The old behavior is now
>   ^^^^^^ remove
> 
> I don't see breakpoint set in the main executable becomes "<pending>"
> (with and without this patch applied), if the following steps are what
> you meant.
> 
> (gdb) b main
> Breakpoint 1 at 0x80484c1: file
> ../../../../git/gdb/testsuite/gdb.base/wchar.c, line 29.
> 
> (gdb) file
> No executable file now.
> Discard symbol table from
> `/home/yao/Source/gnu/gdb/build-git/x86/gdb/testsuite/gdb.base/wchar'?
> (y or n) y
> Error in re-setting breakpoint 1: No symbol table is loaded.  Use the
> "file" command.
> No symbol file now.
> (gdb) info breakpoints

That's with "gdb PROGRAM".  If you do "gdb -ex "file PROGRAM" instead,
you get:

$ ./gdb -q -ex "file ~/gdb/tests/main"

Reading symbols from ~/gdb/tests/main...done.
(gdb) b main
Breakpoint 1 at 0x4004cf: file main.c, line 5.
(gdb) file
No executable file now.
Discard symbol table from `/home/pedro/gdb/tests/main'? (y or n) y
No symbol file now.
(gdb) info breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <PENDING>          main
(gdb)

Note how currently break-unload-file.exp is expecting
the <pending>, and is passing today.  That's only because the
testsuite always uses "file PROGRAM".

The patch does:

-	gdb_test "info break" "y.*PENDING.*foo" \
-	    "breakpoint is pending"
+	# This test used to behave differently depending on whether
+	# the program was first loaded through "file PROGRAM" or "gdb
+	# PROGRAM".
+	set ws "\[ \t\]"
+	gdb_test "info break" "breakpoint${ws}+keep${ws}+n${ws}+$hex${ws}*" \
+	    "breakpoint is disabled"

... and also makes break-unload-file.exp load the PROGRAM into
GDB using both forms (runs the whole test file once for each form).
Without the code patch, that "info break" would show PENDING in one
case, but not on the other.

> shared library loaded by program   OBJF_SHARED
> add-symbol-file foo                OBJF_SHARED | OBJF_USERLOADED
> symbol-file or file foo            OBJF_USERLOADED
> ./gdb foo                          Neither

Correct.

>>       shlib_disabled so they end up uninserted on the next global
>>       location list update.  Shared libraries not loaded by the user
>>       aren't handled here -- they're already handled in
>>       disable_breakpoints_in_unloaded_shlib, called by solib.c's
>>       solib_unloaded observer.  We skip objfiles that are not
>> -     OBJF_USERLOADED (nor OBJF_SHARED) as those aren't considered
>> -     dynamic objects (e.g. the main objfile).  */
>> -  if ((objfile->flags & OBJF_USERLOADED) == 0)
>> +     OBJF_SHARED as those aren't considered dynamic objects (e.g. the
>> +     main objfile).  */
>> +  if ((objfile->flags & OBJF_SHARED) == 0
>> +      || (objfile->flags & OBJF_USERLOADED) == 0)
>>      return;
> 
> ... these are clear too, but shouldn't we only check
> "(objfile->flags & OBJF_SHARED) == 0" here? which means objfile is a
> shared library loaded by program or is added by add-symbol-file can
> be processed afterwards.

Shared libraries loaded by program (or more correctly, automatically
managed by the solib framework) are handled by
disable_breakpoints_in_unloaded_shlib, as the comment above explains:

"Shared libraries not loaded by the user aren't handled here -- they're already
handled in disable_breakpoints_in_unloaded_shlib, called by solib.c's
solib_unloaded observer."

-- 
Pedro Alves