Downloadable Application Questions - VxWorks
This is a discussion on Downloadable Application Questions - VxWorks ; 1. Are there any tricks to reducing the size of downloadable
applications? To improve integration & debugging, I broke out half of
our application code into a downloadable application (the rest is a
bootable image). Typically, our application is around ...
-
Downloadable Application Questions
1. Are there any tricks to reducing the size of downloadable
applications? To improve integration & debugging, I broke out half of
our application code into a downloadable application (the rest is a
bootable image). Typically, our application is around 4MB, but when I
break out the code into a downloadable app, the resulting .out is
35MB. We are developing in C++ on VxWorks 5.4 & Tornado 2.0.2.
2. Is there any way to update the VTable for a class when downloading
an application module? For example consider the following class:
class UUT{
public:
virtual void virtMethod();
void nonVirtMethod();
};
Assume that both method collaborate with class Collaborator. Both UUT
and Collaborator are part of the original bootable image and a new
downloadable application is compiled and partially linked with an
unmodified version of UUT and a modified version of Collaborator.
After the downloadable application is loaded and linked into vxWorks,
calls to UUT::nonVirtMethod will invoke the updated methods in
Collaborator. However, calls to UUT::virtMethod will still end up
calling the old Collaborator (through the original UUT).
-
Re: Downloadable Application Questions
On Jun 26, 4:00 pm, Mears wrote:
> 1. Are there any tricks to reducing the size of downloadable
> applications? To improve integration & debugging, I broke out half of
> our application code into a downloadable application (the rest is a
> bootable image). Typically, our application is around 4MB, but when I
> break out the code into a downloadable app, the resulting .out is
> 35MB. We are developing in C++ on VxWorks 5.4 & Tornado 2.0.2.
>
On what architecture? x86? PPC? ARM? MIPS?
Exactly how are you measuring the size of your application code? Are
you using ls -l to look at the size of the .o file, or are you using
the size utility? This is why I asked you what CPU arch you're using:
there's a separate instance of size for each different arch. Let's
assume you're using PPC. If so, you can do:
% sizeppc myAppModule.o
This should show you the size of the code, text and bss segments in
your module. Only the text and data segments have bearing on the
module size, and I strongly suspect you don't actually have 35MB
worth.
If this is the case, then here's another question: are you compiling
with -g? If so, then the bulk of the file may just contain debugging
symbol information that you don't need. Either build your code without
-g, or use the strip utility to remove the debug symbols:
% stripppc --strip-debug myAppModule.o
> 2. Is there any way to update the VTable for a class when downloading
> an application module? For example consider the following class:
>
> class UUT{
> public:
> virtual void virtMethod();
> void nonVirtMethod();
>
> };
>
> Assume that both method collaborate with class Collaborator. Both UUT
> and Collaborator are part of the original bootable image and a new
> downloadable application is compiled and partially linked with an
> unmodified version of UUT and a modified version of Collaborator.
> After the downloadable application is loaded and linked into vxWorks,
> calls to UUT::nonVirtMethod will invoke the updated methods in
> Collaborator. However, calls to UUT::virtMethod will still end up
> calling the old Collaborator (through the original UUT).
Sorry, I don't know about C++ to answer this.
-Bill