[patch] solib-svr4.c: Document why we need section info of the dynamic linker.

[patch] solib-svr4.c: Document why we need section info of the dynamic linker.

[Doug Evans]

Hi.

This patch is based on info from Daniel on irc.
It documents why we don't call create_solib_event_breakpoint (sym_addr)
unless we have section info on the dynamic linker.

I'll check it in tomorrow if there are no objections.

For the ARM case, one *could* try to pass a non-addr_bits_remove'd
address to create_solib_event_breakpoint and get that working.
Another hacky thought is to fake the necessary section/symbol info
when gdb can't find the dynamic linker (which can happen for cross-debugging
via gdbserver).

That is left for a later pass.  This patch just documents what's there today.

2010-01-26  Doug Evans  <dje@google.com>

	* solib-svr4.c (enable_break): Document why we need section info
	of the dynamic linker.

Index: solib-svr4.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-svr4.c,v
retrieving revision 1.115
diff -u -p -r1.115 solib-svr4.c
--- solib-svr4.c	14 Jan 2010 21:16:52 -0000	1.115
+++ solib-svr4.c	26 Jan 2010 20:36:06 -0000
@@ -1307,6 +1308,26 @@ enable_break (struct svr4_info *info, in
 							      sym_addr,
 							      &current_target));
 
+      /* On at least some versions of Solaris there's a dynamic relocation
+	 on _r_debug.rtld_db_dlactivity (or however it's spelled on Solaris)
+	 and SYM_ADDR may not be relocated yet, e.g., if we get control
+	 before the dynamic linker has self-relocated.  Check if SYM_ADDR is
+	 in a known section, if it is assume we can trust its value.
+	 This is just a heuristic though, it could go away or be replaced if
+	 it's getting in the way.
+
+	 On ARM we need to know whether the ISA of rtld_db_dlactivity (or
+	 however it's spelled in your particular system) is ARM or Thumb.
+	 That knowledge is encoded in the address, if it's Thumb the low bit
+	 is 1.  However, we've stripped that info above and it's not clear
+	 what all the consequences are of passing a non-addr_bits_remove'd
+	 address to create_solib_event_breakpoint.  The call to
+	 find_pc_section verifies we know about the address and have some
+	 hope of computing the right kind of breakpoint to use (via
+	 symbol info).  It does mean that GDB needs to be pointed at a
+	 non-stripped version of the dynamic linker in order to obtain
+	 information it already knows about.  Sigh.  */
+
       os = find_pc_section (sym_addr);
       if (os != NULL)
 	{

Re: [patch] solib-svr4.c: Document why we need section info of the dynamic linker.

[Daniel Jacobowitz]

On Tue, Jan 26, 2010 at 12:41:19PM -0800, Doug Evans wrote:
> +      /* On at least some versions of Solaris there's a dynamic relocation
> +	 on _r_debug.rtld_db_dlactivity (or however it's spelled on Solaris)

It's _r_debug.r_brk.  The function is _dl_debug_state.

I'm curious, does bionic use rtld_db_dlactivity (for either the
function name or field name)?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] solib-svr4.c: Document why we need section info of the dynamic linker.

[Doug Evans]

On Tue, Jan 26, 2010 at 12:46 PM, Daniel Jacobowitz
<dan@codesourcery.com> wrote:
> On Tue, Jan 26, 2010 at 12:41:19PM -0800, Doug Evans wrote:
>> +      /* On at least some versions of Solaris there's a dynamic relocation
>> +      on _r_debug.rtld_db_dlactivity (or however it's spelled on Solaris)
>
> It's _r_debug.r_brk.  The function is _dl_debug_state.

Righto.

> I'm curious, does bionic use rtld_db_dlactivity (for either the
> function name or field name)?

The field name is r_brk, the function name (on android) is
__dl_rtld_db_dlactivity