This is the mail archive of the
mailing list for the GDB project.
Re: [patch] Fixes problem setting breakpoint in dynamic loader
- From: PAUL GILLIAM <pgilliam at us dot ibm dot com>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 05 Jul 2006 16:57:23 -0700
- Subject: Re: [patch] Fixes problem setting breakpoint in dynamic loader
- References: <email@example.com> <200606172021.k5HKL82O013629@elgar.sibelius.xs4all.nl>
- Reply-to: pgilliam at us dot ibm dot com
On Sat, 2006-06-17 at 22:21 +0200, Mark Kettenis wrote:
> > From: PAUL GILLIAM <firstname.lastname@example.org>
> > Date: Wed, 24 May 2006 16:26:11 -0700
> > --=-z0a1QHXPsj5sKoA5562L
> > Content-Type: text/plain
> > Content-Transfer-Encoding: 7bit
> > On PowerPC-64, with 64-bit executables, GDB has been giving this message
> > for a while:
> > warning: Unable to find dynamic linker breakpoint function.
> > GDB will be unable to debug shared library initializers
> > and track explicitly loaded dynamic code.
> > This is because "enable_break()" in solib-svr4.c was looking for the
> > symbol "._dl_debug_state" in the 64-bit dynamic loader and not finding
> > it. This should not be a surprise because these 'dot' symbols have not
> > been used for a while.
> Your patch removes "._dl_debug_state" from the list of symbols.
> Doesn't this break debugging old binaries that still have the 'dot'
No. The non-'dot' symbol "_dl_debug_state" will either be found in a
code segment or in a data segment. If found in a code segment, we can
set the breakpoint at where ever the symbol points. If it points to a
function descriptor that's OK because if it's in the code segment, a
function descriptor consists of executable code and a breakpoint can be
set there. If found in the data segment, then it must be a function
descriptor and it just gets "dereferenced".
So I am attaching a new patch that addresses most of your comments in
and deletes the "._dl_debug_state" entry in the table.
One thing not addressed is this:
> Also, I don't mind that the comment was rearranged, but I would like
> to see information regarding the two linker symbols retained in some
The two linker symbols issue is no longer relevant for this piece of
code: the "._dl_debug_state" symbol was just a crutch used to avoid
having to "dereference" the function descriptor pointed to by
"_dl_debug_state", should it happen to be in a data section. Now there
is code to do just that.
OK to commit?
2006-07-04 Paul Gilliam <email@example.com
* solib-svr4.c (enable_break): Resolve break address when the symbol
is found in the data section.
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 6 Jul 2006 00:50:51 -0000
@@ -85,16 +85,6 @@
- /* 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. */
@@ -1043,20 +1033,38 @@
/* 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)
+ if (sym_addr == 0)
+ CORE_ADDR sect_offset;
+ /* No symbol was found in a code section, so look elsewhere. */
+ 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)
+ if (sym_addr != 0)
+ /* Convert 'sym_addr' from a function pointer to an address. */
+ sym_addr = gdbarch_convert_from_func_ptr_addr (current_gdbarch,
/* We're done with both the temporary bfd and target. Remember,
closing the target closes the underlying bfd. */
target_close (tmp_bfd_target, 0);
2006-05-25 Paul Gilliam <firstname.lastname@example.org
*rs6000-tdep.c (rs6000_convert_from_func_ptr_addr): Use target_ops.
RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v
retrieving revision 1.258
diff -a -u -r1.258 rs6000-tdep.c
--- rs6000-tdep.c 23 Apr 2006 14:15:01 -0000 1.258
+++ rs6000-tdep.c 23 Jun 2006 21:22:32 -0000
@@ -2338,7 +2338,8 @@
inferior's memory space, with all its drawbacks. To be able to
call C++ virtual methods in the inferior (which are called via
function pointers), find_function_addr uses this function to get the
- function address from a function pointer. */
+ function address from a function pointer. It is also used by
+ enable_break from svr4_solib_create_inferior_hook. */
/* Return real function address if ADDR (a function pointer) is in the data
space and is therefore a special function pointer. */
@@ -2355,7 +2356,9 @@
/* ADDR is in the data space, so it's a special function pointer. */
- return read_memory_addr (addr, gdbarch_tdep (current_gdbarch)->wordsize);
+ return get_target_memory_unsigned (targ, addr,
+ gdbarch_tdep (current_gdbarch)->wordsize);