[RFC/ia64-linux] pb with shared libraries when attaching to process

[RFC/ia64-linux] pb with shared libraries when attaching to process

[Joel Brobecker]

Hello,

It's something I hadn't noticed before with gdb-6.8 because there
was no visible symptoms on the machine I used to do the testing.
But with another machine, I get the following type of error:

        (gdb) att 31147
        Attaching to program: /taff.a/brobecke/regr/ex/foo, process 31147
        Reading symbols from /lib/tls/libc.so.6.1...done.
        Loaded symbols for /lib/tls/libc.so.6.1
        Reading symbols from /lib/ld-linux-ia64.so.2...done.
        Loaded symbols for /lib/ld-linux-ia64.so.2
        0xa000000000010641 in __kernel_syscall_via_break ()
        (gdb) c
        Continuing.
 !!! -> Can't insert breakpoint for slot numbers greater than 2.

The reason for the error message is that GDB is trying to insert
a shlib breakpoint at an address that is invalid for ia64:

    (gdb) maintenance info break
    Num     Type           Disp Enb Address            What
    -1      shlib events   keep y   0x200000000003b768 <local+168>

(the slot number is encoded in the last 4 bits of the address and
should be either 0, 1, or 2).

With older versions of GDB (we were using gdb-6.6), we used to break
on one of the SOLIB_BREAK_NAMES routines, whichever is found first.
In our case, gdb-6.6 was showing:

    (gdb) maintenance info break
    Num Type           Disp Enb Address            What
    -1  shlib events   keep y   0x200000000001b720 <_dl_debug_state>

I think this is the right location to break, as I wrote a little
C program that does a dlopen, and I could witness the breakpoint
being triggered when I "next" over the dlopen operation (again,
with gdb-6.6):

    (gdb) next
    [...]
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x200000000001acd0
    infrun: BPSTAT_WHAT_CHECK_SHLIBS
    [...]

With gdb-6.8, we now first try r_brk, and only if it doesn't work
do we fallback on the previous method.

This address is stored at DEBUG_BASE + lmo->r_brk_offset. For LP64,
the r_brk_offset is set to 16 bytes, so that's DEBUG_BASE + 16.
As far as I can tell, the DEBUG_BASE value that we compute seems
correct - we obtain it from the DT_DEBUG dynamic tag, and the value
matches the address of the "_r_debug" symbol. So it's not obviously
wrong.

Assuming that the DEBUG_BASE is correct, dumping the memory at
this address shows:

 40a28 <_r_debug>:   0x00000001      0x00000000      0x00040a50     0x20000000
 40a38 <_r_debug+16>:0x0003b768      0x20000000      0x00000000     0x00000000
 40a48 <_r_debug+32>:0x00000000      0x20000000      0x00000000     0x00000000
 40a58:              0x000287a0      0x20000000      0x0000d988     0x60000000
 40a68:              0x00041500      0x20000000      0x00000000     0x00000000
 40a78:              0x00040a50      0x20000000      0x00000000     0x00000000
 40a88:              0x00040ea0      0x20000000      0x00000000     0x00000000
 40a98:              0x0000d988      0x60000000      0x0000da78     0x60000000
 40aa8:              0x0000da68      0x60000000      0x0000d9f8     0x60000000
 40ab8:              0x0000da08      0x60000000      0x0000da18     0x60000000

First it confirms why we've determine that r_brk is at 0x200000000003b768.
It also seems to say that the address of _dl_debug_state isnt' saved
in that memory region.

Note that, even in the case when the r_brk address found does not cause
the error, it is still incorrect, as I dont see it being triggered
when stepping over dlopen().

Not knowing how things work underneath, I am a bit stuck. I tried finding
some documentation on how things are supposed to work, to no avail.
What do you guys think? bug in the loader? Problem in the debugger?

Thanks,
-- 
Joel

Re: [RFC/ia64-linux] pb with shared libraries when attaching to process

[Daniel Jacobowitz]

On Thu, Apr 24, 2008 at 06:23:31PM -0700, Joel Brobecker wrote:
>     (gdb) maintenance info break
>     Num     Type           Disp Enb Address            What
>     -1      shlib events   keep y   0x200000000003b768 <local+168>
> 
> (the slot number is encoded in the last 4 bits of the address and
> should be either 0, 1, or 2).

So what's actually at that address?  Dump a couple of words... my
first guess is that it ends up being a function descriptor for
_dl_debug_state, but GDB is somehow failing to convert it back into
the breakpoint address.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC/ia64-linux] pb with shared libraries when attaching to process

[Joel Brobecker]

> > (the slot number is encoded in the last 4 bits of the address and
> > should be either 0, 1, or 2).
> 
> So what's actually at that address?  Dump a couple of words... my
> first guess is that it ends up being a function descriptor for
> _dl_debug_state, but GDB is somehow failing to convert it back into
> the breakpoint address.

Indeed!

   (gdb) x /2x 0x200000000003b768
   0x200000000003b768 <local+168>: 0x0001b720      0x20000000
   (gdb) x /i 0x200000000001b720
   0x200000000001b720 <_dl_debug_state>:   [MIB]       nop.m 0x0

Looking deeper into this, the problem is that GDB determins that
this symbol is in the .data section. The code that recognizes
function descriptors for ia64 checks first that the associated
section name is ".opd", or else checks the name of the symbol
with is_vtable_name() (see ia64-tdep.c:ia64_convert_from_func_ptr_addr).

I double checked /lib/ld-linux-ia64.so.2, and unless I'm mistaken,
the debugger is correct. Our address is inside the .data section
of the loader. There is no .opd section in sight.

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .hash         00000280  0000000000000120  0000000000000120  00000120  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .dynsym       00000888  00000000000003a0  00000000000003a0  000003a0  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .dynstr       00000401  0000000000000c28  0000000000000c28  00000c28  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .gnu.version  000000b6  000000000000102a  000000000000102a  0000102a  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .gnu.version_d 00000080  00000000000010e0  00000000000010e0  000010e0  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .rela.dyn     00001bc0  0000000000001160  0000000000001160  00001160  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .rela.IA_64.pltoff 00000078  0000000000002d20  0000000000002d20  00002d20  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .plt          00000120  0000000000002da0  0000000000002da0  00002da0  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  8 .text         00024450  0000000000002ec0  0000000000002ec0  00002ec0  2**6
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  9 .rodata       00002722  0000000000027310  0000000000027310  00027310  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .IA_64.unwind_info 00001008  0000000000029a38  0000000000029a38  00029a38  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 11 .IA_64.unwind 00000b28  000000000002aa40  000000000002aa40  0002aa40  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 12 .data         00004180  000000000003b568  000000000003b568  0002b568  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 13 .dynamic      00000170  000000000003f6e8  000000000003f6e8  0002f6e8  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 14 .got          000000e8  000000000003f858  000000000003f858  0002f858  2**3
                  CONTENTS, ALLOC, LOAD, DATA, SMALL_DATA
 15 .IA_64.pltoff 00000050  000000000003f940  000000000003f940  0002f940  2**4
                  CONTENTS, ALLOC, LOAD, DATA, SMALL_DATA
 16 .sdata        00000868  000000000003f990  000000000003f990  0002f990  2**3
                  CONTENTS, ALLOC, LOAD, DATA, SMALL_DATA
 17 .sbss         0000010c  00000000000401f8  00000000000401f8  000301f8  2**3
                  ALLOC, SMALL_DATA
 18 .bss          00000748  0000000000040308  0000000000040308  000301fc  2**3
                  ALLOC
 19 .comment      00000535  0000000000000000  0000000000000000  000301fc  2**0
                  CONTENTS, READONLY

-- 
Joel

Re: [RFC/ia64-linux] pb with shared libraries when attaching to process

[Daniel Jacobowitz]

On Thu, Apr 24, 2008 at 07:36:23PM -0700, Joel Brobecker wrote:
> Looking deeper into this, the problem is that GDB determins that
> this symbol is in the .data section. The code that recognizes
> function descriptors for ia64 checks first that the associated
> section name is ".opd", or else checks the name of the symbol
> with is_vtable_name() (see ia64-tdep.c:ia64_convert_from_func_ptr_addr).
> 
> I double checked /lib/ld-linux-ia64.so.2, and unless I'm mistaken,
> the debugger is correct. Our address is inside the .data section
> of the loader. There is no .opd section in sight.

Well, you'll have to ask someone more familiar with IA-64 than I at
this point.  I'm not sure why that might be.  But my guess is that
it's legitimate and GDB simply should adapt.

You'd need a link map from the build of ld.so to say for sure.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC/ia64-linux] pb with shared libraries when attaching to process

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 2161 bytes --]

> > Looking deeper into this, the problem is that GDB determins that
> > this symbol is in the .data section. The code that recognizes
> > function descriptors for ia64 checks first that the associated
> > section name is ".opd", or else checks the name of the symbol
> > with is_vtable_name() (see ia64-tdep.c:ia64_convert_from_func_ptr_addr).
> > 
> > I double checked /lib/ld-linux-ia64.so.2, and unless I'm mistaken,
> > the debugger is correct. Our address is inside the .data section
> > of the loader. There is no .opd section in sight.

Eric Botcazou suggested that an address pointing to the .data section
should never be some code because the .data section is not executable;
So we could simply check the flags of our section, and if it doesn't
have the CODE flag set, then assume it's a function descriptor.

I have succesfully tested the following patch with gdb-6.8 (HEAD is
having some issues causing the inferior to fail to start with a SIGILL
at the moment - I'll look at that next).

2008-04-25  Joel Brobecker  <brobecker@adacore.com>

        * ia64-tdep.c (ia64_convert_from_func_ptr_addr): Treat addresses
        pointing inside a non-executable section as function descriptors.

Results before and after the patch:
+------------+------------+----------------------------------------------------+
|       FAIL | PASS       | attach.exp: after attach2, reach tbreak postloop   |
|       FAIL | PASS       | attach.exp: after attach2, exit                    |
| UNRESOLVED | PASS       | attach.exp: before attach3, flush exec             |
| UNRESOLVED | PASS       | attach.exp: attach when process' a.out not in cwd  |
|       FAIL | PASS       | attach.exp: c                                      |
+------------+------------+----------------------------------------------------+

The attached patch is something that I would consider for gdb-6.8.
For gdb-head, I might even go one step farther and remove the check
for the .opd section name just above, since the new check should
handle the .opd section as well.

I'm also wondering about the vtable-related symbols, but that's
harder for me to verify...

What do you think?

-- 
Joel

[-- Attachment #2: fundesc.diff --]
[-- Type: text/plain, Size: 682 bytes --]

Index: ia64-tdep.c
===================================================================
--- ia64-tdep.c	(revision 130268)
+++ ia64-tdep.c	(working copy)
@@ -3328,6 +3328,12 @@ ia64_convert_from_func_ptr_addr (struct 
   if (s && strcmp (s->the_bfd_section->name, ".opd") == 0)
     return read_memory_unsigned_integer (addr, 8);
 
+  /* If ADDR points to a section that is not executable, then it cannot
+     be pointing to a function.  So it must be pointing to a function
+     descriptor.  */
+  if (s && (s->the_bfd_section->flags & SEC_CODE) == 0)
+    return read_memory_unsigned_integer (addr, 8);
+
   /* There are also descriptors embedded in vtables.  */
   if (s)
     {

Re: [RFC/ia64-linux] pb with shared libraries when attaching to process

[Daniel Jacobowitz]

On Fri, Apr 25, 2008 at 10:59:52AM -0700, Joel Brobecker wrote:
> Eric Botcazou suggested that an address pointing to the .data section
> should never be some code because the .data section is not executable;
> So we could simply check the flags of our section, and if it doesn't
> have the CODE flag set, then assume it's a function descriptor.

I can imagine this breaking but it would require use of mprotect.
Your patch looks good to me.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC/ia64-linux] pb with shared libraries when attaching to process

[Joel Brobecker]

> On Fri, Apr 25, 2008 at 10:59:52AM -0700, Joel Brobecker wrote:
> > Eric Botcazou suggested that an address pointing to the .data section
> > should never be some code because the .data section is not executable;
> > So we could simply check the flags of our section, and if it doesn't
> > have the CODE flag set, then assume it's a function descriptor.
> 
> I can imagine this breaking but it would require use of mprotect.
> Your patch looks good to me.

Thanks. I just checked the patch in.

-- 
Joel