This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
[RFA] Add new comment
- To: gdb-patches at sources dot redhat dot com
- Subject: [RFA] Add new comment
- From: Joel Brobecker <brobecker at act-europe dot fr>
- Date: Thu, 7 Jun 2001 15:19:35 +0200
Hi,
in solib-osf.c, the osf_in_dynsym_resolve_code function has been recently
added. While porting gdb to Tru64 5.1 on our side, we did exactly the same,
except that we added some comments explaining the consequences of always
returning 0. I am hoping that you find this comment useful.
Here is the ChangeLog entry:
2001-06-07 J. Brobecker <brobecker@act-europe.fr>
* solib-osf.c (osf_in_dynsym_resolve_code): Add a comment explaining
the consequences of always returning 0.
--
Joel
Index: solib-osf.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-osf.c,v
retrieving revision 1.1
diff -c -3 -p -r1.1 solib-osf.c
*** solib-osf.c 2001/05/26 00:52:13 1.1
--- solib-osf.c 2001/06/07 13:18:49
*************** osf_open_symbol_file_object (void *from_
*** 589,594 ****
--- 589,600 ----
static int
osf_in_dynsym_resolve_code (CORE_ADDR pc)
{
+ /* This function currently always return False. This is a temporary
+ solution which only consequence is to introduce a minor incovenience
+ for the user: When stepping inside a subprogram located in a shared
+ library, gdb might stop inside the dynamic loader code instead of
+ inside the subprogram itself. See the explanations in infrun.c about
+ the IN_SOLIB_DYNSYM_RESOLVE_CODE macro for more details. */
return 0;
}