87 lines
3.3 KiB
Diff
87 lines
3.3 KiB
Diff
|
2006-05-25 Paul Gilliam <pgilliam@us.ibm.com
|
||
|
|
||
|
* solib-svr4.c: Remove "._dl_debug_state" from the list of symbols at
|
||
|
which to try setting a breakpoint for tracking solibs.
|
||
|
(enable_break): Resolve break address when the symbol is found in
|
||
|
the data section.
|
||
|
|
||
|
Index: solib-svr4.c
|
||
|
===================================================================
|
||
|
RCS file: /cvs/src/src/gdb/solib-svr4.c,v
|
||
|
retrieving revision 1.58
|
||
|
diff -a -u -r1.58 solib-svr4.c
|
||
|
--- solib-svr4.c 18 May 2006 20:38:56 -0000 1.58
|
||
|
+++ solib-svr4.c 25 May 2006 22:12:55 -0000
|
||
|
@@ -85,16 +85,6 @@
|
||
|
"rtld_db_dlactivity",
|
||
|
"_rtld_debug_state",
|
||
|
|
||
|
- /* On the 64-bit PowerPC, the linker symbol with the same name as
|
||
|
- the C function points to a function descriptor, not to the entry
|
||
|
- point. The linker symbol whose name is the C function name
|
||
|
- prefixed with a '.' points to the function's entry point. So
|
||
|
- when we look through this table, we ignore symbols that point
|
||
|
- into the data section (thus skipping the descriptor's symbol),
|
||
|
- and eventually try this one, giving us the real entry point
|
||
|
- address. */
|
||
|
- "._dl_debug_state",
|
||
|
-
|
||
|
NULL
|
||
|
};
|
||
|
|
||
|
@@ -1043,20 +1033,45 @@
|
||
|
/* Now try to set a breakpoint in the dynamic linker. */
|
||
|
for (bkpt_namep = solib_break_names; *bkpt_namep != NULL; bkpt_namep++)
|
||
|
{
|
||
|
- /* On ABI's that use function descriptors, there are usually
|
||
|
- two linker symbols associated with each C function: one
|
||
|
- pointing at the actual entry point of the machine code,
|
||
|
- and one pointing at the function's descriptor. The
|
||
|
- latter symbol has the same name as the C function.
|
||
|
-
|
||
|
- What we're looking for here is the machine code entry
|
||
|
- point, so we are only interested in symbols in code
|
||
|
- sections. */
|
||
|
+ /* What we're looking for here is the machine code entry point,
|
||
|
+ so we are only interested in symbols in code sections.
|
||
|
+
|
||
|
+ On ABI's that use function descriptors, the linker symbol with
|
||
|
+ the same name as a C funtion points to that functions descriptor.
|
||
|
+ when those function descriptors are in the code section, they
|
||
|
+ contain executable code and we can set a breakpoint there. */
|
||
|
sym_addr = bfd_lookup_symbol (tmp_bfd, *bkpt_namep, SEC_CODE);
|
||
|
if (sym_addr != 0)
|
||
|
break;
|
||
|
}
|
||
|
|
||
|
+ if (sym_addr == 0)
|
||
|
+ {
|
||
|
+ CORE_ADDR sect_offset;
|
||
|
+
|
||
|
+ /* No symbol was found in a code section, so look in the data
|
||
|
+ sections. This will only happen when the linker symbol points
|
||
|
+ to a function descriptor that is in a data section. */
|
||
|
+ for (bkpt_namep = solib_break_names; *bkpt_namep!=NULL; bkpt_namep++)
|
||
|
+ {
|
||
|
+ /* On ABI's that use function descriptors that are in the data
|
||
|
+ section, */
|
||
|
+ sym_addr = bfd_lookup_symbol (tmp_bfd, *bkpt_namep, SEC_DATA);
|
||
|
+ if (sym_addr != 0)
|
||
|
+ break;
|
||
|
+ }
|
||
|
+ if (sym_addr == 0)
|
||
|
+ {
|
||
|
+ target_close (tmp_bfd_target, 0);
|
||
|
+ goto bkpt_at_symbol;
|
||
|
+ }
|
||
|
+
|
||
|
+ /* Convert 'sym_addr' from a function pointer to an address. */
|
||
|
+ sym_addr = gdbarch_convert_from_func_ptr_addr (current_gdbarch,
|
||
|
+ sym_addr,
|
||
|
+ tmp_bfd_target);
|
||
|
+ }
|
||
|
+
|
||
|
/* We're done with both the temporary bfd and target. Remember,
|
||
|
closing the target closes the underlying bfd. */
|
||
|
target_close (tmp_bfd_target, 0);
|