[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference caldec::wrl_atom

Title:ATOM Tool Development System
Moderator:CALDEC::SCHMIDT
Created:Tue Sep 07 1993
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:309
Total number of notes:979

301.0. "Exclude object from an included shared object???" by CICS03::helen (Helen Pratt) Thu May 08 1997 05:38




A partner is trying to use the hiprof tool to profile part of their
application.  They are using hiprof V2.29 on Digital UNIX V4.0A.

The problem is that they need to instrument their libraries with
the code.  One of these libraries contains objects built from assembly
language, atom appears to handle these with messages of the following nature:

atom: Warning: Object '/opt/cics/lib/libcicsrt.so' has invalid instruction at 0x6fd9fd44, treating as data.


This I can handle, however after many, many of the above warnings, we get
the following assertion:

Assertion failed: InstOp(prtl) == B_OP || InstOp(prtl) == FB_OP || InstOp(prtl) == BR_OP || InstOp(prtl) == BSR_OP, file /home/glyons/sb/adk_kit/src/usr/ccs/bin/atom/Atom/aom/rtl.c, line 1051
atom: Error: Command '/tmp/atomAAAaaccGa/hp.tool' terminated with receipt of SIGABRT signal.


The command being used to instrument this is as follows:

	atom hp -tool hiprof -env threads -heapbase taso \
		-toolargs="-pids" -all -L/opt/cics/lib \
		-L/opt/encina/lib

So a couple of questions:

1. Can anyone suggest alternative flags/options which might prevent
this from occurring.

2. Can explicitly exclude an object from within an included shared 
object file?

Thanks for any help,

Helen.
T.RTitleUserPersonal
Name		DateLines
301.1A workaroundSMURF::JPWJohn P Williams, DUDE, USG, 381-2079Thu May 08 1997 06:4522
Hiprof has a -exc flag, but since the failure appears to be 
in the common Atom code,I suspect that will not help here.

So, I figure that if this partner's library can be supported
at all, we will need to enhance Atom to do so. I expect the
primary Atom developer will have more insightful words on this
so stay tuned.

The workaround that comes to mind is something that the partner
can do right away. It is to avoid the warnings and/or the assert,
by not asking atom to process the modules it is having trouble with.
These are the options:
	- Link the offending modules in a separate shared library,
	  and then specify "-excobj <offending_lib.so>" on the 
	  atom command line (I think Atom will ignore them then).
	- Recompile or recode the offending modules so that there
	  are no unrecognized instructions or data in the text section
	  of the object file. For example, compile to use only "ev4"
	  instructions, or move the data into a different section.
	  The comments at the assert site in Atom suggest that the
	  partner's library has an instruction that is expected to
	  be be a branch but does not have a recognized op-code.
301.2Undocumented flag ?CICS03::helenHelen PrattThu May 08 1997 07:3021

John,

Thanks for the prompt reply.  I can reproduce the customers problem on
my system (I have a slightly earlier build of their software running).

I tried using -exc, but I don't think that bought me much...

However I was fairly certain in some mails I exchanged with Greg Lueck
about a year ago that he described a flag which could be used - I don't
think it's supported as such given that it's not on the man page.  Anyway
at the moment I'm giving that a go.

Unfortunately I don't think the work around is going to be viable, although
in many way's it's probably the cleanest, however I will mention it to them
if I get nowhere with the above.

Thanks,

Helen.
301.3More InfoNNTPD::&quot;[email protected]&quot;Gail LyonsThu May 08 1997 14:1111
Helen -

I recall Greg Lueck working with you last spring, providing the switch for
you.
I would be interested if that works.   It should remove the warning messages,
but I don't know if it will help with the assertion.  Please let me know.

Gail Lyons

[Posted by WWW Notes gateway]
301.4wCICS03::helenHelen PrattFri May 09 1997 01:2318
Gail,

I have managed to instrument my version of the code and the customer
has also managed to instrument theirs.  They're working on the list of
libraries to exclude given that they don't want profiling info for everything.

My next concern is actually running the instrumented version of the code.
At the moemnt I haven't managed to get my system into a state to test
the code for various completely unrelated reasons....

In the past I have not managed to get the code to run properly - it'll
be interesting to see if this is different with hiprof.
I'll post a note on how I get on running it!

Regards,

Helen