This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[RFA] Add new comment


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;
  }
  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]