RTP file without symbols, smaller files
Andi
I want do make the vxe files smaller, they are to big now.
So I used the strip tool and removed debug info and comments. When I
remove more, for example the symbols, the RTP can not be started. Can
somebody tell me which parts are really used by the loader. Which
sections can be removed?
Thanks
Andi
PAD
RTP executables are relocatable. It is therefore required to keep the
relocation sections and symbol table (which imposes to keep the string
table as well). Essentially removing the debug information is about
all you can do.
Out of curiosity, are you using static RTP executables or dynamic RTP
executables (i.e. using shared libraries)?
Cheers,
--
PAD
Andi
thanks for your information.
Till now we work with static executables, we don't use shared
libraries yet.
But it's planned to make some libraries shared, to save memory space.
If we have statically linked RTPs, for what is the relocation needed?
Is there any possibility to remove at least the internal symbols?
Thanks
Andy
Jason
Try
strip --strip-unneeded myrtp.vxe
That should remove everything you don't need, but keep stuff you need
for relocating. Note you can still point Workbench at the original
unstripped
file in order to get all the debugging symbols, which is super cool
Jason
mariole
Hi PAD,
Thank you for your answer, unfortunately vxworks uses ELF (Executable
and Linkable Format) for its files (kernel module and RTPs)
Reading the OMF (Object and Module Format) also know as relocatable,
you will notice that:
[cite]
Note that this specification is not applicable for vendors choosing to
build products with the
Executable and Linkable Format (ELF), because ELF is both a linkable
and loadable
specification.
[\cite]
source: http://www.x86.org/ftp/manuals/tools/omf.pdf
Regards
--
Eric
Andi
-----
Hi Jason
I use the command <stripppc --remove-section=.comment --strip-unneeded
myrtp.vxe>.
It's surprising that still so many relocations are neccessary.
I thought that in a statically linked RTP all libraries are statically
linked.
In a really simple C++ sample are many relocations to strlen, strcpy,
malloc, semGive, semTake, ...
Why is this so?
Andy
----
What happens if you don't use "--remove-section=.comment",
i.e. just do --strip-unneeded.
That's what I do, and it reduces a 60MB RTP (with -g) to ~ 5MB,
so something of that order; I don't have the details in front of me.
You can use objdumpppc -t myrtp.vxe after that to see what's left
in the file.
I wouldn't expect there to be very much needed for relocation
Jason
---
Hi Jason
I have tried --strip-unneeded. It gives the same result as --remove-
section=.comment --strip-unneeded, except that the comments are still
present.
With which tool chain do you work? Also gcc version 3.4.4 (Wind River
vxworks-6.5) (built 20070108)?
Andy
p.s. Sorry that I have sent you an email directly. I pushed the wrong
button.
PAD
On Jun 24, 11:43 pm, Andi <aander...@hamilton-medical.ch> wrote:
>
> Till now we work with static executables, we don't use shared
> libraries yet.
> But it's planned to make some libraries shared, to save memory space.
Ok. Are you storing the .vxe files on ROMFS? Are you starting your
user-side application via the shell or programmatically (this makes a
difference because the default for RTPs spawned via the kernel shell
is to create a on-system symbol table for each of those RTPs, hence
adding to the RAM consumption).
> If we have statically linked RTPs, for what is the relocation needed?
This is the way RTPs are designed and implemented : the executable
files are meant to be relocated. The underlying reason is the very
varied memory maps on VxWorks systems due to the hardware
characteristics as well as the highly configurable and tunable nature
of VxWorks. This is not to say that it is impossible to statically
link RTP executables for their execution address and therefore skip
the relocation phase but the way VxWorks 6.x currently handles the
virtual address space does not make this easy.
> Is there any possibility to remove at least the internal symbols?
Even local symbols are needed for the relocation process.
--
PAD
Andi
>
Hi PAD
Are local symbols called by relative jumps so these jumps could be
relocated by the linker?
Is it possible to run some kind of relocater, store the result in a
file and start the application from this file?
This way many symbols wouldn't be neccassary at start time.
Andy
PAD
On Jun 30, 12:17 am, Andi <aander...@hamilton-medical.ch> wrote:
>
> Are local symbols called by relative jumps so these jumps could be
> relocated by the linker?
Local symbols are indeed used for calls within the application code
but are also used to get access to the content of local variables. The
instructions referring to those symbols are subjected to the
relocation process done by, in this case, the RTP loader. The details
vary from processor architecture to processor architecture and vary as
well depending on the way the relocation information is encoded, and I
would not pretend to know/remember all of it.
> Is it possible to run some kind of relocater, store the result in a
> file and start the application from this file?
> This way many symbols wouldn't be neccassary at start time.
Possibly but I think that, due to the nature of the relocation
information, you'd have to know where in virtual memory the text and
data/bss segments are going to be installed. Unfortunately you don't
know this ahead of time.
--
PAD
Andi
Thanks for all your information, now I can understand the VXE files
better.
Andy
todi...@gmail.com
> link RTP executables for their execution address and therefore skip
> the relocation phase but the way VxWorks 6.x currently handles the
> virtual address space does not make this easy.
I was wondering if you could elaborate on the matter of statically linking RTP executables to fixed execution addresses, in order to eliminate the relocation phase so that symbols could be stripped from them entirely (as you mentioned in one of your posts here).
I understand that it may prove difficult, but if it's possible, I'd very much like to know how, as this is a requirement in a project I'm working on.
Thanks,
Tomer Godinger.
PAD
Since this is reviving an old thread, I should start by stating that VxWorks 6.8 (possibly 6.7, I do not remember) introduced support for overlapped virtual memory which made possible to also support absolutely linked RTP executables. These are executables that are linked at the execution address chosen by the user (this strongly depends on the hardware too). Such executables can then be stripped of their symbols, string table and relocation information.
If you are using a recent version of VxWorks this would directly address your needs.
Best regards.
todi...@gmail.com
That is good to know, but unfortunately, I'm using VxWorks 6.3 (I suppose I should have mentioned that sooner).
How would one go about performing this feat without the features introduced in 6.7/6.8?
Thanks,
Tomer Godinger.
PAD
This truly is a hard one. Conceptually this is relatively simple: you need to get an executable file linked for a given execution address, you need to allocate enough memory for that file's segments from about this given execution address, then you need to read the file's text, data and bss segments and copy them at the proper address in memory, finally you have to call the application's entry point as indicated in that file.
However each one of those steps listed above requires the full cooperation of the OS and the compiler toolchain, and that is truly not there for you in VxWorks releases prior to VxWorks 6.8 (or may be 6.7). If you have the VxWorks source code and are willing to design and implement your own version of the support for absolutely linked RTP executables then you should be able to do it. Without the source code I don't see any way to get what you want. Note that I am not talking about the support for the overlapped virtual memory, which is the foundation for the official support of absolutely linked RTP executables.
A difficult problem is that the initial task of an RTP, created by the rtpSpawn() API, does the memory allocation and the loading of the RTP executable file. If you do not call rtpSpawn() then you do not create an RTP that the system recognizes and can handle. But if you call rtpSpawn() then you lose control over the loading of the executable file. So you'd have to either replace the official RTP loader with a simpler loader or modify it so that it allocates the area of virtual memory you want (in both cases the API would be pgMgrPageAllocAt() but I am not 100% sure it is a published API). If modifying the official RTP loader you'd have to make it skip the relocation process.
At this point the issue is in getting the appropriate area of virtual memory reserved by the system for RTP usage. I think this is possible via the BSP's sysPhysMemDesc[] array but I am fairly certain that this involves an attribute which is not published. WR support should be able to provide you with this attribute though.
Another problem is getting the compiler toolchain to generate an absolutely linked RTP executable. This requires a different linker script from the one used in pre-VxWorks 6.8/6.7 releases. Although it is possible to tell the compiler toolchain to use an alternate linker script, the writing of such script is rather arcane and I am sorry to say that I do not have good advices for that. Finally this absolutely linked executable files could be stripped of its symbols and relocation information, although in older versions of VxWorks the strip utility was not tested against RTP executable and is known to be buggy on some architectures...
All in all this is really quite an endeavor.
todi...@gmail.com
Thank you very much for the detailed explanation!
I have been in touch with WR support, but your posts have provided me with much more useful information.
It certainly appears to be a very difficult undertaking.
Enough so that it gives cause to pause before proceeding, and consider alternatives.
Do you believe it would be easier, for example, to remove loaded symbols from memory after loading a DKM or an RTP?
I know for sure that symbols loaded from a DKM are retained (that is, after all, more or less the purpose of a DKM, as I understand), and I suspect that they exist in the memory area used by loaded RTPs, though I have not been able to confirm this yet.
Such a possibility might allow me to avoid the tremendous efforts you described.
On the other hand, strange as it may sound, I find the challenge of manually loading an RTP to an absolute address rather appealing. =)
I believe that I can manage allocating the memory area for RTP use fairly easily (I've done something similar before), and the rest should be... interesting to attempt.
I do have one more question for you, though, if you would be so kind:
I have noticed that static global functions do not get their symbols included in the .vxe file. Is it possible to extend this effect to classes, as well - or even better, to namespaces?
My attempts to do so have yielded no success.
Once again, thank you dearly for your aid.
It has been most invaluable, and is greatly appreciated.
Good day,
Tomer.