From: Taimoor <tmirza@codesourcery.com>
To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Improving GDB's mechanism to check if function is GC'ed
Date: Tue, 02 Jun 2015 13:38:00 -0000 [thread overview]
Message-ID: <556DB1BB.50601@codesourcery.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2742 bytes --]
Hi,
GDB currently uses following mechanism to check if function is GC'ed by
the linker:
For any function whose address is 0x0, if 'textlow' field of partial
symbol table is not zero, function is considered to be GC'ed by the
linker. Below is the code doing this:
case DW_LNE_set_address:
address = read_address (abfd, line_ptr, cu, &bytes_read);
/* If address < lowpc then it's not a usable value, it's
outside the pc range of the CU. However, we restrict
the test to only address values of zero to preserve
GDB's previous behaviour which is to handle the specific
case of a function being GC'd by the linker. */
if (address == 0 && address < lowpc)
{
/* This line table is for a function which has been
GCd by the linker. Ignore it. PR gdb/12528 */
This change was done in
https://sourceware.org/ml/gdb-patches/2014-08/msg00468.html
This does not work for cases where symbols are manually loaded using
add-symbol-file command. For any incrementally loaded objfile whose
symbols are added using add-symbol-file command can have function at 0x0
in debug info and can have its lowpc non-zero because of add-symbol-file
command that allows user to provide section addresses.
Current Problem
===============
We are currently using GDB to debug Nucleus based bare-metal system that
also allows to dynamically load and unload Nucleus process modules
during system execution.
We currently load symbols of a modules using add-symbol-file whenever a
module is loaded at runtime. It is very common to have functions at
address 0x0 in debug information and then lowpc in symbol table to be
non-zero as it depends on section addresses given in add-symbol-file
command.
With above mentioned GC'ing mechanism, GDB assumes that all these
functions are GC'ed by linker. Because of this breakpoints do not work
properly in debug session.
Possible Solution
=================
* Modify GC checking mechanism to mark any function GC'ed using above
mentioned mechanism only if objfile is not dynamically loaded. So, for
any function with address 0x0, it'll be marked GC'ed only if lowpc is
not zero and objfile is main symbol file.
For this I have made following modifications in if condition:
if (address == 0 && address < lowpc
&& (objfile->flags & OBJF_MAINLINE))
{
I have regression tested this change and it seems to work fine.
Only downside that it is possible (though not common) to load main
symbol file using add-symbol-file command. In that case, GDB will not
check for GC'ed functions.
Attached is patch to better highlight this solution.
I am open to any other suggestions to improve this GC'ing mechanism and
solving this problem.
Thanks,
Taimoor
[-- Attachment #2: gdb_function_garbageCollection.patch --]
[-- Type: text/x-patch, Size: 651 bytes --]
diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index f6b0c01..4f84b40 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -17665,7 +17665,8 @@ dwarf_decode_lines_1 (struct line_header *lh, struct dwarf2_cu *cu,
the test to only address values of zero to preserve
GDB's previous behaviour which is to handle the specific
case of a function being GC'd by the linker. */
- if (address == 0 && address < lowpc)
+ if (address == 0 && address < lowpc
+ && (objfile->flags & OBJF_MAINLINE))
{
/* This line table is for a function which has been
GCd by the linker. Ignore it. PR gdb/12528 */
next reply other threads:[~2015-06-02 13:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-02 13:38 Taimoor [this message]
2015-06-09 6:16 ` Taimoor
2015-06-09 13:36 ` Yao Qi
2015-06-10 8:54 ` Yao Qi
2015-06-10 10:17 ` Pedro Alves
2015-06-10 12:04 ` Taimoor
2015-06-10 12:07 ` Yao Qi
2015-06-10 14:43 ` Pedro Alves
2015-06-11 8:30 ` Yao Qi
2015-06-11 8:54 ` Pedro Alves
2015-06-10 11:18 ` Luis Machado
2015-06-10 11:46 ` Taimoor
2015-06-10 12:25 ` Yao Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=556DB1BB.50601@codesourcery.com \
--to=tmirza@codesourcery.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox