Hi,

can someone please help me get the symbol-name
corresponding to a address for a different process
other than self. The problem is I have the ip(instruction
pointer) at which a process I am tracing with
ptrace calls, but I don't know how to get corressponding
function name. I can get the symbol name contained
in the corresponding executable but I don't know the
way for shared library it is using(as they are mapped
to different addresses for different process) and it
also open shared library dynamically using dlopen() call.

regards,
Dilip

[ Post a follow-up to this message ]

In article <414046B0.9080808@yahoo.co.in>,
dilipkc <chhetri_inside@yahoo.co.in> wrote:

> Hi,
>
>   can someone please help me get the symbol-name
> corresponding to a address for a different process
> other than self. The problem is I have the ip(instruction
> pointer) at which a process I am tracing with
> ptrace calls, but I don't know how to get corressponding
> function name. I can get the symbol name contained
> in the corresponding executable but I don't know the
> way for shared library it is using(as they are mapped
> to different addresses for different process) and it
> also open shared library dynamically using dlopen() call.

Take a look at the gdb source and see how it does it.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[ Post a follow-up to this message ]

Barry Margolin <barmar@alum.mit.edu> writes:

> In article <414046B0.9080808@yahoo.co.in>,
>  dilipkc <chhetri_inside@yahoo.co.in> wrote:
> 
>
> Take a look at the gdb source and see how it does it.
>

That is not a very useful advice I am afraid: gdb sources are
quite difficult to decipher even for people who *know* the answer
to OP's question, which is:

You need to know:

1. which libraries are loaded (so you can read their symbol tables)
2. where in memory they are loaded (base address)
3. what load address they were linked for (usually, but not
necessarily 0).

The way to find an answer to all of the above is system-specific.

Since OP is posting from hp.com using Linux, I do not know which
system to provide further details for. On Linux, _r_debug.r_map
contains answers to [1] and [2], and [3] can be found by reading
Elf32_Phdr's from the appropriate place in the elf.so

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]

Paul Pluzhnikov wrote:
> Barry Margolin <barmar@alum.mit.edu> writes:
>
> 
>
I tried that but it was a nightmare

>
> That is not a very useful advice I am afraid: gdb sources are
> quite difficult to decipher even for people who *know* the answer
> to OP's question, which is:
>
> You need to know:
>
> 1. which libraries are loaded (so you can read their symbol tables)
Could you tell me what elf-section it is stored in and in what
format.

> 2. where in memory they are loaded (base address)
Again, is it stored in some sections ?

> 3. what load address they were linked for (usually, but not
>    necessarily 0).
In my case the same library are getting loaded at different
addresses for different executables(I discovered it using gdb).

>
> The way to find an answer to all of the above is system-specific.
>
> Since OP is posting from hp.com using Linux, I do not know which


I wanted to know this for HPUX-11.23 on itanium.

> system to provide further details for. On Linux, _r_debug.r_map
> contains answers to [1] and [2], and [3] can be found by readi
ng
> Elf32_Phdr's from the appropriate place in the elf.so
>
> Cheers,

[ Post a follow-up to this message ]

dilipkc <chhetri_inside@yahoo.co.in> writes:
 
>
> Could you tell me what elf-section it is stored in and in what
> format.

This can't be stored in any section, because the list is *dynamic*.
It changes every time you dlopen() or dlclose() a library.
 
> Again, is it stored in some sections ?

Ditto. If you 'dlopen("libfoo.so"); ... dlclose("libfoo.so");
... dlopen("libfoo.so");' there is no guarantee that libfoo.so will
be loaded at the same address the second time.
 

Now, that *is* stored in the library itself.
For example, 'elfdump  -o /lib/hpux32/libc.so' shows (among other
things):

Phdr #:  4          Type:    Loadable
Offset:  0x00000000 Vaddr:   0x04000000
Paddr:   0x00000000 Fsize:   0x00266cf0
Memsz:   0x00266cf0 Flags:   -l-c--- r-x
Align:   0x00000000

Phdr #:  5          Type:    Loadable
Offset:  0x00267000 Vaddr:   0x40000000
Paddr:   0x00000000 Fsize:   0x00008f58
Memsz:   0x00013428 Flags:   --m---- rw-
Align:   0x00000010

That means, that if /lib/hpux32/libc.so is loaded at (say)
0x7ed30000, and "nm -px /lib/hpux32/libc.so | grep ' mmap$'"
prints: "0x04219080 T  mmap", then the address of mmap in memory
is going to be 0x04219080 - 0x04000000 + 0x7ed30000 == 0x7ef49080.

Gdb confirms this:

(gdb) p/a 0x04219080 - 0x04000000 + 0x7ed30000
$3 = 0x7ef49080:0 <mmap>
[vbcol=seagreen]
> In my case the same library are getting loaded at different
> addresses for different executables(I discovered it using gdb).

No surprises there. The libraries are usually loaded into the first
address range still available.

> I wanted to know this for HPUX-11.23 on itanium.

Now you are talking. On HP-UX, you find the dynamic list by
repeatedly calling shl_get_r(), like this:

#include <dl.h>
#include <stdio.h>
int main()
{
struct shl_descriptor desc;
int i = -1;
int rc = shl_get_r(i++, &desc); /* info for the dynamic loader itself */

printf("text\t\tdata\n");
printf("%p\t%p\t%s\n", desc.tstart, desc.dstart, desc.filename);
while (0 == rc) {
rc = shl_get_r(i++, &desc);
printf("%p\t%p\t%s\n", desc.tstart, desc.dstart, desc.filename);
}
return 0;
}

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]

> This can't be stored in any section, because the list is *dynamic*.
> It changes every time you dlopen() or dlclose() a library.
>
You are right, I see that something called "loadmap" address is
being stored in ".dynamic" section( tag = DT_HP_LOAD_MAP ), looks
like I am able to retrive it correctly but don't know how to get
the list of shared-library loaded and at what address

> Now, that *is* stored in the library itself.
> For example, 'elfdump  -o /lib/hpux32/libc.so' shows (among other
> things):
>
> Phdr #:  4          Type:    Loadable
> Offset:  0x00000000 Vaddr:   0x04000000
> Paddr:   0x00000000 Fsize:   0x00266cf0
> Memsz:   0x00266cf0 Flags:   -l-c--- r-x
> Align:   0x00000000
>
> Phdr #:  5          Type:    Loadable
> Offset:  0x00267000 Vaddr:   0x40000000
> Paddr:   0x00000000 Fsize:   0x00008f58
> Memsz:   0x00013428 Flags:   --m---- rw-
> Align:   0x00000010
>
> That means, that if /lib/hpux32/libc.so is loaded at (say)
> 0x7ed30000, and "nm -px /lib/hpux32/libc.so | grep ' mmap$'"
> prints: "0x04219080 T  mmap", then the address of mmap in memory
> is going to be 0x04219080 - 0x04000000 + 0x7ed30000 == 0x7ef49080.
>
This is really informative, I am going to need this computatuion

>
>
> Now you are talking. On HP-UX, you find the dynamic list by
> repeatedly calling shl_get_r(), like this:
>
> #include <dl.h>
> #include <stdio.h>
> int main()
> {
>   struct shl_descriptor desc;
>   int i = -1;
>   int rc = shl_get_r(i++, &desc); /* info for the dynamic loader itself */
>
>   printf("text\t\tdata\n");
>   printf("%p\t%p\t%s\n", desc.tstart, desc.dstart, desc.filename);
>   while (0 == rc) {
>     rc = shl_get_r(i++, &desc);
>     printf("%p\t%p\t%s\n", desc.tstart, desc.dstart, desc.filename);
>   }
>   return 0;
> }

This one seems to be intresting code, I hope this will solve my problem.

Thanks a ton Paul :-)

[ Post a follow-up to this message ]