From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,156107aae7c00a69 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-05-31 06:37:34 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!logbridge.uoregon.edu!netnews.com!feed2.onemain.com!feed1.onemain.com!out.nntp.be!propagator-dallas!news-in-dallas.newsfeeds.com!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <9f2jl6$l89$1@newstoo.ericsson.se> <2E6R6.5179$rn5.256863@www.newsranger.com> <9f4oae$2tc$1@newstoo.ericsson.se> Subject: Re: Profiling using VxWorks and AdaMULTI. Message-ID: X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Thu, 31 May 2001 09:36:55 EDT Organization: http://www.newsranger.com Date: Thu, 31 May 2001 13:36:55 GMT Xref: archiver1.google.com comp.lang.ada:7928 Date: 2001-05-31T13:36:55+00:00 List-Id: In article <9f4oae$2tc$1@newstoo.ericsson.se>, Petter Fryklund says... > >We've already been in contact with GHS, they haven't yet found out what >TickTime is. I've also tried to get in contact with WRS. I've just hoping >that somebody out there knew. Well, it doesn't appear to be anything in vxWorks (which shouldn't be shocking, since you apparently *don't* have it). I can't find any reference to it in vxWorks 5.3 or 5.4, and it is not a symbol in our 5.4 kernel. The only explanations I can think of are that it either: a) is a symbol that the GreenHills profiler uses. That seems rather unlikely, as it then wouldn't work for anyone. b) is a symbol used by some code of yours (most likely custom C code linked into the kernel) that happens to have the same name as a kernel subroutine. Everything in vxWorks exists in the same symbol space, so its quite possible for this kind of thing to happen (another good reason to not use C). When linking a kernel, I don't think there are any checks for undefined or redefined references. To check for b), first see if you have any (non-WindRiver) code being linked into your kernel. If you do, look through it for the offending symbol. If its found in there, you have 2 problems: 1 - there's an undefined symbol you have to do something with; 2 - something that is calling that has the same name as a kernel (or profiler) routine, and *must* be renamed. We had something similar to b) happen to us. There was a C routine which we were reusing from another project which happened to have a routine named "checksum" in it. When we took our first kernel out to a system to try it out, we couldn't get networking to work. We couldn't even ping the loopback address. It turns out that "checksum" is also the name of a routine in the TCP/IP stack, and we were inadvertantly replacing it with our C program's "checksum" routine. Whoops. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com