[ARM] dlopen and remote debugging

[ARM] dlopen and remote debugging

[karthikeyan.s]

Hi,
We recently encountered an issue with gdb wherein it does not get the
symbols from a shared library when loaded with dlopen. The following
steps does not give us the shared library's symbols. The binary is
Xorg.

1)
<target> gdbserver :10000 /usr/bin/X -ac
<host gdb> set sysroot <targetfs_path>
<host gdb> target remote 10.0.0.3:10000
<host gdb> continue
<host> cntrl-C
We do not get the library's symbols here. But with cat
/proc/{x_pid}/maps we can see the library is loaded in memory.

2) But with the following steps, the libraries get loaded
<target>  /usr/bin/X -ac &
<target> gdbserver :10000 --attach <X_pid>
<host gdb> set sysroot <targetfs_path>
<host gdb> target remote 10.0.0.3:10000

We can see the library's symbols and hit breakpoint, debug etc. etc.

Architecture - ARM cortex-a9
toolchain - codesourcery arm-none-linux-gnueabi
gdb version - 7.1.50 (almost the latest!)
The library built with -g2 -ggdb and  is not stripped.

Any reason for the first method to not load the symbols? What part of
gdb code should I dig into for this?

Regards,
Karthik

Re: [ARM] dlopen and remote debugging

[Matthew Gretton-Dann]

Karthik,

On Thu, 2010-06-24 at 23:42 +0530, karthikeyan.s wrote:
> Hi,
> We recently encountered an issue with gdb wherein it does not get the
> symbols from a shared library when loaded with dlopen. The following
> steps does not give us the shared library's symbols. The binary is
> Xorg.
> 
> 1)
> <target> gdbserver :10000 /usr/bin/X -ac
> <host gdb> set sysroot <targetfs_path>
> <host gdb> target remote 10.0.0.3:10000
> <host gdb> continue
> <host> cntrl-C
> We do not get the library's symbols here. But with cat
> /proc/{x_pid}/maps we can see the library is loaded in memory.
> 
> 2) But with the following steps, the libraries get loaded
> <target>  /usr/bin/X -ac &
> <target> gdbserver :10000 --attach <X_pid>
> <host gdb> set sysroot <targetfs_path>
> <host gdb> target remote 10.0.0.3:10000
> 
> We can see the library's symbols and hit breakpoint, debug etc. etc.
> 

Section 20.3.2 of the gdb manual says that you need to load the symbols
for your application using the file command before you connect (see
http://sourceware.org/gdb/download/onlinedocs/gdb/Server.html#Server).
Can you try this, and report back if you are still having problems?

I would imagine the commands to your host gdb would be something like:
(gdb) set sysroot <targetfs_path>
(gdb) file <program_being_debugged>
(gdb) target remote 10.0.0.3:10000
(gdb) continue

Thanks,

Matt

-- 
Matthew Gretton-Dann
Principal Engineer - PDSW Tools
ARM Ltd

Re: [ARM] dlopen and remote debugging

[karthikeyan.s]

Sorry I did not mention that we do start gdb with the binary app X.
So in the host we start with:
$ arm-none-linux-gnueabi-gdb <targetfs_path>/usr/bin/X

and then
 # (gdb) set sysroot <targetfs_path>
 # (gdb) target remote 10.0.0.3:10000
 # (gdb) continue

I think one does not need to specify the source binary again.

1) One difference I see in the working and non-working case is that
other libraries that X depends on are stripped in the failing case.
So if X depends on x.so,y.so,our_driver.so. In the failing case, case
x.so,y.so are stripped. Not that this is the reason for the failure,
but just a difference in the conditions in succeeding and failing
case.
And X is stripped in both the cases.

2) Also, with the above method, I could manually specify the .text
address (along with values of variables too by specifying other
section addresses) of the library using add-file-symbol. And then was
able to hit breakpoints disassemble the library.

add-symbol-file <targetfs_path>/usr/lib/xorg/driver.so <text address>
<text address> = library load address + text offset in the library.

-Karthik

On Fri, Jun 25, 2010 at 6:17 PM, Matthew Gretton-Dann
<matthew.gretton-dann@arm.com> wrote:
> Karthik,
>
> On Thu, 2010-06-24 at 23:42 +0530, karthikeyan.s wrote:
>> Hi,
>> We recently encountered an issue with gdb wherein it does not get the
>> symbols from a shared library when loaded with dlopen. The following
>> steps does not give us the shared library's symbols. The binary is
>> Xorg.
>>
>> 1)
>> <target> gdbserver :10000 /usr/bin/X -ac
>> <host gdb> set sysroot <targetfs_path>
>> <host gdb> target remote 10.0.0.3:10000
>> <host gdb> continue
>> <host> cntrl-C
>> We do not get the library's symbols here. But with cat
>> /proc/{x_pid}/maps we can see the library is loaded in memory.
>>
>> 2) But with the following steps, the libraries get loaded
>> <target>  /usr/bin/X -ac &
>> <target> gdbserver :10000 --attach <X_pid>
>> <host gdb> set sysroot <targetfs_path>
>> <host gdb> target remote 10.0.0.3:10000
>>
>> We can see the library's symbols and hit breakpoint, debug etc. etc.
>>
>
> Section 20.3.2 of the gdb manual says that you need to load the symbols
> for your application using the file command before you connect (see
> http://sourceware.org/gdb/download/onlinedocs/gdb/Server.html#Server).
> Can you try this, and report back if you are still having problems?
>
> I would imagine the commands to your host gdb would be something like:
> (gdb) set sysroot <targetfs_path>
> (gdb) file <program_being_debugged>
> (gdb) target remote 10.0.0.3:10000
> (gdb) continue
>
> Thanks,
>
> Matt
>
> --
> Matthew Gretton-Dann
> Principal Engineer - PDSW Tools
> ARM Ltd
>
>



-- 
---
S. Karthikeyan | +919980814745
---

Re: [ARM] dlopen and remote debugging

[karthikeyan.s]

Can anyone give us a direction here? pointers to related code in gdb
would also be fine.

On Fri, Jun 25, 2010 at 8:47 PM, karthikeyan.s <informkarthik@gmail.com> wrote:
> Sorry I did not mention that we do start gdb with the binary app X.
> So in the host we start with:
> $ arm-none-linux-gnueabi-gdb <targetfs_path>/usr/bin/X
>
> and then
>  # (gdb) set sysroot <targetfs_path>
>  # (gdb) target remote 10.0.0.3:10000
>  # (gdb) continue
>
> I think one does not need to specify the source binary again.
>
> 1) One difference I see in the working and non-working case is that
> other libraries that X depends on are stripped in the failing case.
> So if X depends on x.so,y.so,our_driver.so. In the failing case, case
> x.so,y.so are stripped. Not that this is the reason for the failure,
> but just a difference in the conditions in succeeding and failing
> case.
> And X is stripped in both the cases.
>
> 2) Also, with the above method, I could manually specify the .text
> address (along with values of variables too by specifying other
> section addresses) of the library using add-file-symbol. And then was
> able to hit breakpoints disassemble the library.
>
> add-symbol-file <targetfs_path>/usr/lib/xorg/driver.so <text address>
> <text address> = library load address + text offset in the library.
>
> -Karthik
>
> On Fri, Jun 25, 2010 at 6:17 PM, Matthew Gretton-Dann
> <matthew.gretton-dann@arm.com> wrote:
>> Karthik,
>>
>> On Thu, 2010-06-24 at 23:42 +0530, karthikeyan.s wrote:
>>> Hi,
>>> We recently encountered an issue with gdb wherein it does not get the
>>> symbols from a shared library when loaded with dlopen. The following
>>> steps does not give us the shared library's symbols. The binary is
>>> Xorg.
>>>
>>> 1)
>>> <target> gdbserver :10000 /usr/bin/X -ac
>>> <host gdb> set sysroot <targetfs_path>
>>> <host gdb> target remote 10.0.0.3:10000
>>> <host gdb> continue
>>> <host> cntrl-C
>>> We do not get the library's symbols here. But with cat
>>> /proc/{x_pid}/maps we can see the library is loaded in memory.
>>>
>>> 2) But with the following steps, the libraries get loaded
>>> <target>  /usr/bin/X -ac &
>>> <target> gdbserver :10000 --attach <X_pid>
>>> <host gdb> set sysroot <targetfs_path>
>>> <host gdb> target remote 10.0.0.3:10000
>>>
>>> We can see the library's symbols and hit breakpoint, debug etc. etc.
>>>
>>
>> Section 20.3.2 of the gdb manual says that you need to load the symbols
>> for your application using the file command before you connect (see
>> http://sourceware.org/gdb/download/onlinedocs/gdb/Server.html#Server).
>> Can you try this, and report back if you are still having problems?
>>
>> I would imagine the commands to your host gdb would be something like:
>> (gdb) set sysroot <targetfs_path>
>> (gdb) file <program_being_debugged>
>> (gdb) target remote 10.0.0.3:10000
>> (gdb) continue
>>
>> Thanks,
>>
>> Matt
>>
>> --
>> Matthew Gretton-Dann
>> Principal Engineer - PDSW Tools
>> ARM Ltd
>>
>>
>
>
>
> --
> ---
> S. Karthikeyan | +919980814745
> ---
>



-- 
---
S. Karthikeyan | +919980814745
---