public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug breakpoints/12528] New: Should we handle constructors that are garbage collected but their debug info isn't?
@ 2011-03-01 22:18 dje at google dot com
2011-03-11 8:12 ` [Bug breakpoints/12528] " dje at google dot com
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: dje at google dot com @ 2011-03-01 22:18 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=12528
Summary: Should we handle constructors that are garbage
collected but their debug info isn't?
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: breakpoints
AssignedTo: unassigned@sourceware.org
ReportedBy: dje@google.com
This is a general problem which normally isn't significant (YMMV).
But in the case of constructors it can happen in real world code.
GCC can emit two copies of a constructor, and then with -ffunction-sections
-Wl,--gc-sections one copy may get thrown away. However the associated debug
info won't get thrown away, leading to gdb lossage.
$ cat c1c2.cc
class foo
{
public:
foo (int x);
int _x;
};
class foo2 : public foo
{
public:
foo2 (int x);
};
foo::foo (int x)
: _x (x)
{
}
foo2::foo2 (int x)
: foo (x)
{ // line 21
}
int
main ()
{
foo2 bar (3);
return 0;
}
$ g++ -g -ffunction-sections -Wl,--gc-sections c1c2.cc
$ gdb a.out
[...]
(gdb) b 21
Breakpoint 1 at 0x20: file c1c2.cc, line 22. (2 locations)
(gdb) i b
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x0000000000000020 c1c2.cc:22
1.2 y 0x00000000004005c8 in foo2::foo2(int)
at c1c2.cc:22
(gdb) r
Starting program: /home/dje/src/play/a.out
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x20: Input/output error.
(gdb)
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug breakpoints/12528] Should we handle constructors that are garbage collected but their debug info isn't?
2011-03-01 22:18 [Bug breakpoints/12528] New: Should we handle constructors that are garbage collected but their debug info isn't? dje at google dot com
@ 2011-03-11 8:12 ` dje at google dot com
2011-03-16 18:15 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: dje at google dot com @ 2011-03-11 8:12 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=12528
dje at google dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ppluzhnikov at google dot
| |com
--- Comment #1 from dje at google dot com 2011-03-11 08:11:32 UTC ---
*** Bug 12568 has been marked as a duplicate of this bug. ***
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug breakpoints/12528] Should we handle constructors that are garbage collected but their debug info isn't?
2011-03-01 22:18 [Bug breakpoints/12528] New: Should we handle constructors that are garbage collected but their debug info isn't? dje at google dot com
2011-03-11 8:12 ` [Bug breakpoints/12528] " dje at google dot com
@ 2011-03-16 18:15 ` cvs-commit at gcc dot gnu.org
2011-03-16 18:16 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2011-03-16 18:15 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=12528
--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> 2011-03-16 18:15:27 UTC ---
CVSROOT: /cvs/src
Module name: src
Changes by: ppluzhnikov@sourceware.org 2011-03-16 18:15:20
Modified files:
gdb : dwarf2read.c ChangeLog
gdb/testsuite : ChangeLog
Added files:
gdb/testsuite/gdb.base: break-on-linker-gcd-function.cc
break-on-linker-gcd-function.exp
Log message:
ChangeLog:
2011-03-16 Paul Pluzhnikov <ppluzhnikov@google.com>
PR gdb/12528
* dwarf2read.c (noop_record_line): New function.
(dwarf_decode_lines): Ignore line tables for GCd functions.
testsuite/ChangeLog:
2011-03-16 Paul Pluzhnikov <ppluzhnikov@google.com>
PR gdb/12528
* gdb.base/Makefile.in: Adjust EXECUTABLES.
* gdb.base/break-on-linker-gcd-function.exp: New test.
* gdb.base/break-on-linker-gcd-function.cc: New file.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/dwarf2read.c.diff?cvsroot=src&r1=1.509&r2=1.510
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.12822&r2=1.12823
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/ChangeLog.diff?cvsroot=src&r1=1.2635&r2=1.2636
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.base/break-on-linker-gcd-function.cc.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.base/break-on-linker-gcd-function.exp.diff?cvsroot=src&r1=NONE&r2=1.1
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug breakpoints/12528] Should we handle constructors that are garbage collected but their debug info isn't?
2011-03-01 22:18 [Bug breakpoints/12528] New: Should we handle constructors that are garbage collected but their debug info isn't? dje at google dot com
2011-03-11 8:12 ` [Bug breakpoints/12528] " dje at google dot com
2011-03-16 18:15 ` cvs-commit at gcc dot gnu.org
@ 2011-03-16 18:16 ` cvs-commit at gcc dot gnu.org
2011-03-16 18:22 ` ppluzhnikov at google dot com
2014-09-19 8:59 ` cvs-commit at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2011-03-16 18:16 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=12528
--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> 2011-03-16 18:16:35 UTC ---
CVSROOT: /cvs/src
Module name: src
Changes by: ppluzhnikov@sourceware.org 2011-03-16 18:16:26
Modified files:
gdb/testsuite/gdb.base: Makefile.in
Log message:
ChangeLog:
2011-03-16 Paul Pluzhnikov <ppluzhnikov@google.com>
PR gdb/12528
* dwarf2read.c (noop_record_line): New function.
(dwarf_decode_lines): Ignore line tables for GCd functions.
testsuite/ChangeLog:
2011-03-16 Paul Pluzhnikov <ppluzhnikov@google.com>
PR gdb/12528
* gdb.base/Makefile.in: Adjust EXECUTABLES.
* gdb.base/break-on-linker-gcd-function.exp: New test.
* gdb.base/break-on-linker-gcd-function.cc: New file.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.base/Makefile.in.diff?cvsroot=src&r1=1.9&r2=1.10
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug breakpoints/12528] Should we handle constructors that are garbage collected but their debug info isn't?
2011-03-01 22:18 [Bug breakpoints/12528] New: Should we handle constructors that are garbage collected but their debug info isn't? dje at google dot com
` (2 preceding siblings ...)
2011-03-16 18:16 ` cvs-commit at gcc dot gnu.org
@ 2011-03-16 18:22 ` ppluzhnikov at google dot com
2014-09-19 8:59 ` cvs-commit at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: ppluzhnikov at google dot com @ 2011-03-16 18:22 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=12528
Paul Pluzhnikov <ppluzhnikov at google dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Paul Pluzhnikov <ppluzhnikov at google dot com> 2011-03-16 18:22:29 UTC ---
Verified original test case is fixed as well.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug breakpoints/12528] Should we handle constructors that are garbage collected but their debug info isn't?
2011-03-01 22:18 [Bug breakpoints/12528] New: Should we handle constructors that are garbage collected but their debug info isn't? dje at google dot com
` (3 preceding siblings ...)
2011-03-16 18:22 ` ppluzhnikov at google dot com
@ 2014-09-19 8:59 ` cvs-commit at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-09-19 8:59 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=12528
--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".
The branch, master has been updated
via 00ba3162ed1633f9b27f3fdd450e076d3a3f2e90 (commit)
via c3b7b696c231416ac90fd9cb7d5ce735b3683356 (commit)
from 8e635c209bd7dbccd410953334a55ff5fc91e81b (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=00ba3162ed1633f9b27f3fdd450e076d3a3f2e90
commit 00ba3162ed1633f9b27f3fdd450e076d3a3f2e90
Author: Yao Qi <yao@codesourcery.com>
Date: Mon Aug 18 09:57:40 2014 +0800
Run dw2-var-zero-addr.exp with --readnow
This patch is to extend dw2-var-zero-add.exp to cover the case that
partial symtabl is not used while full symtab is used, in order to
cover the changes in patch 2/3. This patch restarts GDB with
--readnow and does the same test again.
gdb/testsuite:
2014-09-19 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dw2-var-zero-addr.exp: Move test into new proc test.
Invoke test. Restart GDB with --readnow and invoke test again.
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c3b7b696c231416ac90fd9cb7d5ce735b3683356
commit c3b7b696c231416ac90fd9cb7d5ce735b3683356
Author: Yao Qi <yao@codesourcery.com>
Date: Mon Aug 4 14:57:22 2014 +0800
Check function is GC'ed
I see the following fail on arm-none-eabi target,
(gdb) b 24^M
Breakpoint 1 at 0x4: file
../../../../git/gdb/testsuite/gdb.base/break-on-linker-gcd-function.cc,
line 24.^M
(gdb) FAIL: gdb.base/break-on-linker-gcd-function.exp: b 24
Currently, we are using flag has_section_at_zero to determine whether
address zero in debug info means the corresponding code has been
GC'ed, like this:
case DW_LNE_set_address:
address = read_address (abfd, line_ptr, cu, &bytes_read);
if (address == 0 && !dwarf2_per_objfile->has_section_at_zero)
{
/* This line table is for a function which has been
GCd by the linker. Ignore it. PR gdb/12528 */
However, this is incorrect on some bare metal targets, as .text
section is located at 0x0, so dwarf2_per_objfile->has_section_at_zero
is true. If a function is GC'ed by linker, the address is zero. GDB
thinks address zero is a function's address rather than this function
is GC'ed.
In this patch, we choose 'lowpc' got in read_file_scope to check
whether 'lowpc' is greater than zero. If it isn't, address zero really
means the function is GC'ed. In this patch, we pass 'lowpc' in
read_file_scope through handle_DW_AT_stmt_list and dwarf_decode_lines,
and to dwarf_decode_lines_1 finally.
This patch fixes the fail above. This patch also covers the path that
partial symbol isn't used, which is tested by starting gdb with
--readnow option.
It is regression tested on x86-linux with
target_board=dwarf4-gdb-index, and arm-none-eabi. OK to apply?
gdb:
2014-09-19 Yao Qi <yao@codesourcery.com>
* dwarf2read.c (dwarf_decode_lines): Update declaration.
(handle_DW_AT_stmt_list): Add argument 'lowpc'. Update
comments. Callers update.
(dwarf_decode_lines): Likewise.
(dwarf_decode_lines_1): Add argument 'lowpc'. Update
comments. Skip the line table if 'lowpc' is greater than
'address'. Don't check
dwarf2_per_objfile->has_section_at_zero.
gdb/testsuite:
2014-09-19 Yao Qi <yao@codesourcery.com>
* gdb.base/break-on-linker-gcd-function.exp: Move test into new
proc set_breakpoint_on_gcd_function. Invoke
set_breakpoint_on_gcd_function. Restart GDB with --readnow and
invoke set_breakpoint_on_gcd_function again.
-----------------------------------------------------------------------
Summary of changes:
gdb/ChangeLog | 11 ++++++
gdb/dwarf2read.c | 33 +++++++++++++------
gdb/testsuite/ChangeLog | 12 +++++++
.../gdb.base/break-on-linker-gcd-function.exp | 24 +++++++++++---
gdb/testsuite/gdb.dwarf2/dw2-var-zero-addr.exp | 19 +++++++++--
5 files changed, 80 insertions(+), 19 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-09-19 8:59 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-01 22:18 [Bug breakpoints/12528] New: Should we handle constructors that are garbage collected but their debug info isn't? dje at google dot com
2011-03-11 8:12 ` [Bug breakpoints/12528] " dje at google dot com
2011-03-16 18:15 ` cvs-commit at gcc dot gnu.org
2011-03-16 18:16 ` cvs-commit at gcc dot gnu.org
2011-03-16 18:22 ` ppluzhnikov at google dot com
2014-09-19 8:59 ` cvs-commit at gcc dot gnu.org
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).