home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / vxworks / 998 < prev    next >
Encoding:
Text File  |  1992-11-07  |  2.5 KB  |  56 lines
  1. Newsgroups: comp.os.vxworks
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!fs7.ece.cmu.edu!crabapple.srv.cs.cmu.edu!netnews.srv.cs.cmu.edu!hmp
  3. From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
  4. Subject: Interesting ld68k behavior
  5. Message-ID: <HMP.92Nov6084047@squash.frc.ri.cmu.edu>
  6. Sender: news@cs.cmu.edu (Usenet News System)
  7. Nntp-Posting-Host: squash.frc.ri.cmu.edu
  8. Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
  9. Organization: Field Robotics Center, CMU
  10. Date: Fri, 6 Nov 1992 13:40:47 GMT
  11. Lines: 43
  12.  
  13.  
  14.  
  15. I just thought I'd share an observation I've made recently while
  16. placing vxWorks and application code into ROM.
  17.  
  18. I'm using the rom compression feature, so most of my code gets
  19. crunched into a handy data array. The last step before compression is
  20. to ld68k everything one last time, specifying usrInit() as the entry
  21. point and RAM_TEXT_HIGH_ADDRESS (typically 0x90000) as the start of
  22. the text segment. Then, when the system starts up, romStart()
  23. uncompresses the whole mess, starting at RAM_TEXT_HIGH_ADDRESS, and
  24. then proceeds to jump to the entry point with the call
  25. ((FUNCPTR)RAM_TEXT_HIGH_ADRS) (startType);
  26.  
  27. So far so good, it looks like everything is going according to plan.
  28. My assumption - from looking at how things are done - was that
  29. specifying -e _usrInit and -T 90000 results in usrInit() being placed
  30. at the start of the text segment, since that is the routine we want to
  31. execute when we jump to RAM_TEXT_HIGH_ADDRESS. Sounds reasonable.
  32.  
  33. But imagine my surprise when I added some custom routines at the top
  34. of usrConfig.c (one might argue over the political correctness of
  35. doing so...), and usrInit no longer ended up at RAM_TEXT_HIGH_ADDRESS.
  36. Instead, whatever routine appeared first in usrConfig.c got that
  37. privilege and was subsequently called by romStart. 
  38. The obvious solution was to simply rearrange the order of the routines
  39. usrConfig.c so that usrInit() comes first.
  40.  
  41. But I have to wonder: Is this the way things ought to be? Am I just
  42. missing something fundamental here? Or could it be that somehow the
  43. notion of "entry point" becomes unclear when loading a module by
  44. uncompressing from one part of memory into another?
  45.  
  46. I'd be interested in your comments.
  47.  
  48. -Henning
  49.  
  50.  
  51. --
  52. Henning Pangels    |hmp@frc2.frc.ri.cmu.edu        |     Field Robotics Center
  53. Research Programmer|(412) 268-7088                 |Carnegie-Mellon University
  54. ------------------------------------------------------------------------------
  55.                   It can be difficult to wreck a nice beach.
  56.