Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Finding source lines from COFF executables on OSF1/alpha

20 views
Skip to first unread message

Michael S. Zraly

unread,
Jan 9, 2003, 4:22:13 PM1/9/03
to
On this OS:

% uname -a
OSF1 ex2-dec16 V5.1 732 alpha

with an executable that looks like this:

% file a.out
a.out: COFF format alpha dynamically linked, demand paged
executable or object module not stripped - version 3.13-14

compiled with this:

% cxx -V
Compaq C++ V6.2-024 for Compaq Tru64 UNIX V5.1 (Rev. 732)

Is it possible to take program counter values reported by
exc_capture_context, exc_virtual_unwind, etc., and use them
along with COFF headers in the executable to find the filename
and line numbers associated with them? In other words, can
I generate a dbx/ladebug-like stack trace using values written
from the executable but without having a real corefile?

I know about fork-and-core but that's too heavy handed for
the work I have to do (roll-my-own malloc tracing).

One issue is dynamic libraries: is there any information
I need to get about where dynamic library code is loaded
that I cannot get from the executable itself? Or do I
have to examine the running process to get that first?

Does anyone have any decent examples of using the code
declared in ldfcn.h to find this info in the executable?

Thanks,
Mike Zraly

--
Mike Zraly Every man is as God made him, ay, and
mzr...@world.std.com often worse. -- Miguel de Cervantes

Paul Pluzhnikov

unread,
Jan 10, 2003, 2:04:51 AM1/10/03
to
mzr...@TheWorld.com (Michael S. Zraly) writes:

> I know about fork-and-core but that's too heavy handed for
> the work I have to do (roll-my-own malloc tracing).

Did you try mpatrol?
Perhaps you don't need to write yet another malloc() wrapper
after all?

> One issue is dynamic libraries: is there any information
> I need to get about where dynamic library code is loaded
> that I cannot get from the executable itself? Or do I
> have to examine the running process to get that first?

The latter.

Cheers,
--
In order to understand recursion you must first understand recursion.

Michael S. Zraly

unread,
Jan 10, 2003, 8:45:23 AM1/10/03
to
In article <uptr5o7u...@earthlink.net>,

Paul Pluzhnikov <ppluz...@earthlink.net> wrote:
>mzr...@TheWorld.com (Michael S. Zraly) writes:
>
>> I know about fork-and-core but that's too heavy handed for
>> the work I have to do (roll-my-own malloc tracing).
>
>Did you try mpatrol?
>Perhaps you don't need to write yet another malloc() wrapper
>after all?

I'll look into it, but I'm still interested in this issue,
if only to satisfy my curiosity.

>> One issue is dynamic libraries: is there any information
>> I need to get about where dynamic library code is loaded
>> that I cannot get from the executable itself? Or do I
>> have to examine the running process to get that first?
>
>The latter.

Are there tools for doing this, similar to pmap and related
commands on Solaris? I see OSF does have a proc filesystem,
so presumably this would not be terribly hard to do. Has
someone done this already perchance?

Is there a way for a process to do this to itself? I suppose
a process can read its own proc file...

For that matter is there a way on OSF to generate a core
file? I don't see gcore in the man pages.

Thanks,
Mike


--
Mike Zraly One should forgive one's enemies,
mzr...@world.std.com but not before they are hanged.
-- Heinrich Heine

0 new messages