Re: [PATCH 2/2] gdb: Preserve is-stmt lines when switch between files

[Bernd Edlinger <bernd.edlinger@hotmail.de>]

[-- Attachment #1: Type: text/plain, Size: 2702 bytes --]

Hi Tom, Andrew,

> On 5/15/20 12:39 AM, Andrew Burgess wrote:
>> * Tom Tromey <tom@tromey.com> [2020-05-14 14:18:44 -0600]:
>>
>>>>>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
>>>
>>> Resurrecting this again ... we have some internal tests that have been
>>> failing, and I want to land at least one of these patches to resolve
>>> this.
>>>
>>> Andrew> After reading[2] I'd also be interest to understand what flaw in
>>> Andrew> DWARF you feel makes a difference in this case.
>>>
>>> I also don't understand this.
>>>
> 
> When you only know where an inline function ends at the byte address.
> You can habe line table entries at the same address from the inline
> funcion and from the calling function.  It is impossible to distinguish
> between those, however there is a view number which would be different,
> and as Alexandre explains it, these can be consider an extension to the
> byte addresses, so if a range info would add a view number we would
> know which line infos are from the subroutine and which are not, even
> if the byte addresses are identical.
> 
>>> Andrew> I think it is great Bernd, that you are reaching out from the GCC
>>> Andrew> community to engage with GDB, this is certainly the best way to ensure
>>> Andrew> that we can work together as communities to give the best possible
>>> Andrew> debug experience, and I'm sorry you feel that I have not been clear
>>> Andrew> enough about the issues I'm seeing here.
>>>
>>> +1
>>>

I am always happy to help.

Andrew, and/or Tom, could you please test my patch, obviously one new test
case is still failing, however I would not rule out the possibility, that
we can work together to even fix that, I must say that our cooperation made
things possible, that I would not have expected, like fixing the inline functions
that are not in a header file.

How does this patch work in practice, I would be happy to know what I have
to fix even when Andrews patch lands tomorrow, probably due to a release
schedule?  Attached are again the patch from myself, and test cases from
Andrew's patch.

By the way when is the next gdb release planned?

And let me say this, honestly, I am happy to take the blame for any GCC BUG :-),
that certainly still exists, and ideally those will be fixed in a way that
gdb can figure out that it is fixed, ideally by some kind of dwarf-version
info in the debug info.

What is a given thing that this broken debug info is already there for years,
and historic gcc version will continue to exist for quite a while.  So my goal
is to work around it, communicate with each other, look for solutions, but not
make the users unhappy unless absolutely necessary.



Thanks
Bernd.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-gdb.multi-multi-re-run.exp-with-native-gdbserver.patch --]
[-- Type: text/x-patch; name="0001-Fix-gdb.multi-multi-re-run.exp-with-native-gdbserver.patch", Size: 3722 bytes --]

From 7cfd74cfc6e14034779e6cc048c68877b7a08f88 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Sat, 16 May 2020 18:59:10 +0100
Subject: [PATCH 1/2] Fix gdb.multi/multi-re-run.exp with native-gdbserver

The new exec-file-mismatch feature reveals that when running
gdb.multi/multi-re-run.exp against --target_board=native-gdbserver,
we've been starting gdbserver with the wrong program:

 (gdb) spawn /home/pedro/brno/pedro/gdb/binutils-gdb/build/gdb/testsuite/../../gdbserver/gdbserver --once localhost:2347 /home/pedro/brno/pedro/gdb/binutils-gdb/build/gdb/te
 stsuite/outputs/gdb.multi/multi-re-run/multi-re-run-2
 Process /home/pedro/brno/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.multi/multi-re-run/multi-re-run-2 created; pid = 6280
 Listening on port 2347
 target remote localhost:2347
 Remote debugging using localhost:2347
 warning: Mismatch between current exec-file /home/pedro/brno/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.multi/multi-re-run/multi-re-run-1
 and automatically determined exec-file /home/pedro/brno/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.multi/multi-re-run/multi-re-run-2
 exec-file-mismatch handling is currently "ask"
 Load new symbol table from "/home/pedro/brno/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.multi/multi-re-run/multi-re-run-2"? (y or n) Quit
 (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=1: running to all_started in runto

The problem is that gdb_reload uses the last loaded file as binary to
spawn, but we load the program for inferior 2 and then switch to
inferior 1 and run it, so the last loaded file is the program for
inferior 2.

Fix this by tweaking last_loaded_file.

gdb/testsuite/ChangeLog:
2020-05-16  Pedro Alves  <palves@redhat.com>

	* gdb.multi/multi-re-run.exp (test_re_run): Switch
	LAST_LOADED_FILE accordingly.
---
 gdb/testsuite/ChangeLog                  | 5 +++++
 gdb/testsuite/gdb.multi/multi-re-run.exp | 7 +++++++
 2 files changed, 12 insertions(+)

diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index c57ddf5..0be2fd3 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-05-16  Pedro Alves  <palves@redhat.com>
+
+	* gdb.multi/multi-re-run.exp (test_re_run): Switch
+	LAST_LOADED_FILE accordingly.
+
 2020-05-15  Philippe Waroquiers  <philippe.waroquiers@skynet.be>
 
 	* gdb.base/alias.exp: Verify 'help aliases' shows user defined aliases.
diff --git a/gdb/testsuite/gdb.multi/multi-re-run.exp b/gdb/testsuite/gdb.multi/multi-re-run.exp
index 93cd709..a243293 100644
--- a/gdb/testsuite/gdb.multi/multi-re-run.exp
+++ b/gdb/testsuite/gdb.multi/multi-re-run.exp
@@ -51,6 +51,7 @@ proc test_re_run {re_run_inf} {
     global binfile1 binfile2
     global inferior_exited_re
     global gdb_prompt
+    global last_loaded_file
 
     clean_restart ${binfile1}
 
@@ -65,12 +66,17 @@ proc test_re_run {re_run_inf} {
 
     if {$re_run_inf == 1} {
 	set steady_inf 2
+	set steady_binfile $binfile2
+	set re_run_binfile $binfile1
     } else {
 	set steady_inf 1
+	set steady_binfile $binfile1
+	set re_run_binfile $binfile2
     }
 
     gdb_test "inferior $steady_inf" "Switching to inferior $steady_inf.*" \
 	"switch to steady inferior"
+    set last_loaded_file $steady_binfile
 
     # Run the steady inferior to a breakpoint, and let it stay stopped
     # there.
@@ -81,6 +87,7 @@ proc test_re_run {re_run_inf} {
 
     gdb_test "inferior $re_run_inf" "Switching to inferior $re_run_inf.*" \
 	"switch to re-run inferior"
+    set last_loaded_file $re_run_binfile
 
     # Now run the RE_RUN_INF inferior a couple times.  GDB used to
     # have a bug that caused the second run to fail to load
-- 
1.9.1


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Automatic-date-update-in-version.in.patch --]
[-- Type: text/x-patch; name="0002-Automatic-date-update-in-version.in.patch", Size: 741 bytes --]

From 966dc1a27c55ccb298cb8c7c41c9cc2985cc321a Mon Sep 17 00:00:00 2001
From: GDB Administrator <gdbadmin@sourceware.org>
Date: Sun, 17 May 2020 00:00:06 +0000
Subject: [PATCH 2/2] Automatic date update in version.in

---
 bfd/version.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bfd/version.h b/bfd/version.h
index 810a82e..08a6344 100644
--- a/bfd/version.h
+++ b/bfd/version.h
@@ -16,7 +16,7 @@
 
    In releases, the date is not included in either version strings or
    sonames.  */
-#define BFD_VERSION_DATE 20200516
+#define BFD_VERSION_DATE 20200517
 #define BFD_VERSION @bfd_version@
 #define BFD_VERSION_STRING  @bfd_version_package@ @bfd_version_string@
 #define REPORT_BUGS_TO @report_bugs_to@
-- 
1.9.1