Hello Everyone,
Just had a question for you relating to mapping my code into memory.
Previously I had developed my code on the 21060 because it had more
internal memory space for my code, however now that I have finished
developing the code I wanted to put it into the 21065L which is the
processor I need to use.
This is my problem: the seg_pmco section contains 0x3c62 words that
are
not being mapped to memory due to the code being too large to fit.
(Obviously because there is so much code, just making the segment
larger
will not work because there isnt that much internal memory to work
with). I had a similar problem in seg_dmda, which I solved by moving
some of the data to an external segment I created (in the ldf). I
attempted to do the same thing with the seg_pmco, but with no success.
This was because I have libio.dlb and libc.dlb in that segment, which
are very large, along with a lot of other code which is specific to my
program. libc.dlb and libio.dlb do not appear to be movable, when
using
the expert linker. I tried to use the elfar utility to dissassemble
those libraries so I could move the *.obj files individually. Im
still
working on that, but is there any better way to do this? Would using
memory overlays be helpful? I'm a little unclear as to how I should be
treating this, and Im sure there are many other pople who have run
into
similar problems since those *.dlb's are quite large. Let me know if
using the elfar utlity to break those up into *.obj's is the way to
go... if not what do you suggest? Thanks a lot.
Sincerely,
Matt Weber
21065L w C code... seg_pmco full of libc.dlb, libio.dlb and source
Started by ●August 17, 2005
Reply by ●August 17, 20052005-08-17
On Wed, 17 Aug 2005, mattw_024 wrote:
> Hello Everyone,
>
> Just had a question for you relating to mapping my code into memory.
> Previously I had developed my code on the 21060 because it had more
> internal memory space for my code, however now that I have finished
> developing the code I wanted to put it into the 21065L which is the
> processor I need to use.
>
> This is my problem: the seg_pmco section contains 0x3c62 words that
> are
> not being mapped to memory due to the code being too large to fit.
> (Obviously because there is so much code, just making the segment
> larger
> will not work because there isnt that much internal memory to work
> with). I had a similar problem in seg_dmda, which I solved by moving
> some of the data to an external segment I created (in the ldf). I
> attempted to do the same thing with the seg_pmco, but with no success.
> This was because I have libio.dlb and libc.dlb in that segment, which
> are very large, along with a lot of other code which is specific to my
> program. libc.dlb and libio.dlb do not appear to be movable, when
> using
> the expert linker. I tried to use the elfar utility to dissassemble
> those libraries so I could move the *.obj files individually. Im
> still
> working on that, but is there any better way to do this? Would using
> memory overlays be helpful? I'm a little unclear as to how I should be
> treating this, and Im sure there are many other pople who have run
> into
> similar problems since those *.dlb's are quite large. Let me know if
> using the elfar utlity to break those up into *.obj's is the way to
> go... if not what do you suggest? Thanks a lot.
Howdy Matt,
Generate a map and find out how many of the routines are not actually
used. If you have to generate objects, strip out everything you don't
need and see how big it is. This is non-trivial because you'll have to
modify the symbol table for the linker - it may be easier to just rewrite
the core routines you need so you can create the overlays for your system.
In any case, you will need to know a lot of details about file structure
and how the linker works. I would think using a map file to tell you
where everything is would be easier than disassembling everything. Also
see if you can generate a cross reference listing to make sure everything
you call gets included and everything you don't call gets stripped.
It's not going to be easy, but you'll learn a lot no matter how you do it!
Patience, persistence, truth,
Dr. mike
> Hello Everyone,
>
> Just had a question for you relating to mapping my code into memory.
> Previously I had developed my code on the 21060 because it had more
> internal memory space for my code, however now that I have finished
> developing the code I wanted to put it into the 21065L which is the
> processor I need to use.
>
> This is my problem: the seg_pmco section contains 0x3c62 words that
> are
> not being mapped to memory due to the code being too large to fit.
> (Obviously because there is so much code, just making the segment
> larger
> will not work because there isnt that much internal memory to work
> with). I had a similar problem in seg_dmda, which I solved by moving
> some of the data to an external segment I created (in the ldf). I
> attempted to do the same thing with the seg_pmco, but with no success.
> This was because I have libio.dlb and libc.dlb in that segment, which
> are very large, along with a lot of other code which is specific to my
> program. libc.dlb and libio.dlb do not appear to be movable, when
> using
> the expert linker. I tried to use the elfar utility to dissassemble
> those libraries so I could move the *.obj files individually. Im
> still
> working on that, but is there any better way to do this? Would using
> memory overlays be helpful? I'm a little unclear as to how I should be
> treating this, and Im sure there are many other pople who have run
> into
> similar problems since those *.dlb's are quite large. Let me know if
> using the elfar utlity to break those up into *.obj's is the way to
> go... if not what do you suggest? Thanks a lot.
Howdy Matt,
Generate a map and find out how many of the routines are not actually
used. If you have to generate objects, strip out everything you don't
need and see how big it is. This is non-trivial because you'll have to
modify the symbol table for the linker - it may be easier to just rewrite
the core routines you need so you can create the overlays for your system.
In any case, you will need to know a lot of details about file structure
and how the linker works. I would think using a map file to tell you
where everything is would be easier than disassembling everything. Also
see if you can generate a cross reference listing to make sure everything
you call gets included and everything you don't call gets stripped.
It's not going to be easy, but you'll learn a lot no matter how you do it!
Patience, persistence, truth,
Dr. mike
Reply by ●August 18, 20052005-08-18
I'm assuming you are using VDSP++ 4.0. If so, under Project
Options-Elimination, make sure you have Eliminate unused objects checked. This
should remove any functions that are included in a library but not actually
called. It also removes variables that are deemed unused, which can sometimes
cause problems with debuggig, so be careful.
--- mattw_024 <weberms@webe...> wrote:
> Hello Everyone,
>
> Just had a question for you relating to mapping my code into memory.
> Previously I had developed my code on the 21060 because it had more
> internal memory space for my code, however now that I have finished
> developing the code I wanted to put it into the 21065L which is the
> processor I need to use.
>
> This is my problem: the seg_pmco section contains 0x3c62 words that
> are
> not being mapped to memory due to the code being too large to fit.
> (Obviously because there is so much code, just making the segment
> larger
> will not work because there isnt that much internal memory to work
> with). I had a similar problem in seg_dmda, which I solved by moving
> some of the data to an external segment I created (in the ldf). I
> attempted to do the same thing with the seg_pmco, but with no success.
> This was because I have libio.dlb and libc.dlb in that segment, which
> are very large, along with a lot of other code which is specific to my
> program. libc.dlb and libio.dlb do not appear to be movable, when
> using
> the expert linker. I tried to use the elfar utility to dissassemble
> those libraries so I could move the *.obj files individually. Im
> still
> working on that, but is there any better way to do this? Would using
> memory overlays be helpful? I'm a little unclear as to how I should be
> treating this, and Im sure there are many other pople who have run
> into
> similar problems since those *.dlb's are quite large. Let me know if
> using the elfar utlity to break those up into *.obj's is the way to
> go... if not what do you suggest? Thanks a lot.
>
> Sincerely,
>
> Matt Weber
__________________________________________________
Options-Elimination, make sure you have Eliminate unused objects checked. This
should remove any functions that are included in a library but not actually
called. It also removes variables that are deemed unused, which can sometimes
cause problems with debuggig, so be careful.
--- mattw_024 <weberms@webe...> wrote:
> Hello Everyone,
>
> Just had a question for you relating to mapping my code into memory.
> Previously I had developed my code on the 21060 because it had more
> internal memory space for my code, however now that I have finished
> developing the code I wanted to put it into the 21065L which is the
> processor I need to use.
>
> This is my problem: the seg_pmco section contains 0x3c62 words that
> are
> not being mapped to memory due to the code being too large to fit.
> (Obviously because there is so much code, just making the segment
> larger
> will not work because there isnt that much internal memory to work
> with). I had a similar problem in seg_dmda, which I solved by moving
> some of the data to an external segment I created (in the ldf). I
> attempted to do the same thing with the seg_pmco, but with no success.
> This was because I have libio.dlb and libc.dlb in that segment, which
> are very large, along with a lot of other code which is specific to my
> program. libc.dlb and libio.dlb do not appear to be movable, when
> using
> the expert linker. I tried to use the elfar utility to dissassemble
> those libraries so I could move the *.obj files individually. Im
> still
> working on that, but is there any better way to do this? Would using
> memory overlays be helpful? I'm a little unclear as to how I should be
> treating this, and Im sure there are many other pople who have run
> into
> similar problems since those *.dlb's are quite large. Let me know if
> using the elfar utlity to break those up into *.obj's is the way to
> go... if not what do you suggest? Thanks a lot.
>
> Sincerely,
>
> Matt Weber
__________________________________________________
Reply by ●August 18, 20052005-08-18
Hey Everyone,
I've got a fix for my problem, and thanks for all of your help. Here is the
low-down on how to get around output segments that are full:
"First of all, you should try to use linker elimination to reduce the
footprint of your application.
If what you trying to accomplish is to split a big library into
different memory segments (e.g. block0 and block1), linker "one input
section -> many output sections" feature can be used to accomplish that.
For example:
Pmco0 {
...
INPUT_SECTIONS($OBJECTS(seg_pmco))
...
} > block0_pm
Pmco1 {
...
INPUT_SECTIONS($OBJECTS(seg_pmco))
...
} > block1_pm
Linker will fit 'seg_pmco' sections that do not fit into 'block0_pm'
into 'block1_pm'.
Using overlays does NOT seem like a viable option in your case. In order
to use overlays, the application should be dividable into units based on
execution time behavior. E.g. one part of application used during one
phase, another part is used during another phase, etc.
You can find more details in the help topic for li1040 linker error
message."
Hope this helps Everyone. Creating an external segment and using this method
worked for me.
-----Original Message-----
From: adsp@adsp... [mailto:adsp@adsp...]On Behalf Of Jon
Harris
Sent: 18-Aug-05 9:23 AM
To: adsp@adsp...
Subject: Re: [adsp] 21065L w C code... seg_pmco full of libc.dlb,
libio.dlb and source I'm assuming you are using VDSP++ 4.0. If so, under Project
Options-Elimination, make sure you have Eliminate unused objects checked.
This
should remove any functions that are included in a library but not actually
called. It also removes variables that are deemed unused, which can
sometimes
cause problems with debuggig, so be careful.
--- mattw_024 <weberms@webe...> wrote:
> Hello Everyone,
>
> Just had a question for you relating to mapping my code into memory.
> Previously I had developed my code on the 21060 because it had more
> internal memory space for my code, however now that I have finished
> developing the code I wanted to put it into the 21065L which is the
> processor I need to use.
>
> This is my problem: the seg_pmco section contains 0x3c62 words that
> are
> not being mapped to memory due to the code being too large to fit.
> (Obviously because there is so much code, just making the segment
> larger
> will not work because there isnt that much internal memory to work
> with). I had a similar problem in seg_dmda, which I solved by moving
> some of the data to an external segment I created (in the ldf). I
> attempted to do the same thing with the seg_pmco, but with no success.
> This was because I have libio.dlb and libc.dlb in that segment, which
> are very large, along with a lot of other code which is specific to my
> program. libc.dlb and libio.dlb do not appear to be movable, when
> using
> the expert linker. I tried to use the elfar utility to dissassemble
> those libraries so I could move the *.obj files individually. Im
> still
> working on that, but is there any better way to do this? Would using
> memory overlays be helpful? I'm a little unclear as to how I should be
> treating this, and Im sure there are many other pople who have run
> into
> similar problems since those *.dlb's are quite large. Let me know if
> using the elfar utlity to break those up into *.obj's is the way to
> go... if not what do you suggest? Thanks a lot.
>
> Sincerely,
>
> Matt Weber
__________________________________________________
I've got a fix for my problem, and thanks for all of your help. Here is the
low-down on how to get around output segments that are full:
"First of all, you should try to use linker elimination to reduce the
footprint of your application.
If what you trying to accomplish is to split a big library into
different memory segments (e.g. block0 and block1), linker "one input
section -> many output sections" feature can be used to accomplish that.
For example:
Pmco0 {
...
INPUT_SECTIONS($OBJECTS(seg_pmco))
...
} > block0_pm
Pmco1 {
...
INPUT_SECTIONS($OBJECTS(seg_pmco))
...
} > block1_pm
Linker will fit 'seg_pmco' sections that do not fit into 'block0_pm'
into 'block1_pm'.
Using overlays does NOT seem like a viable option in your case. In order
to use overlays, the application should be dividable into units based on
execution time behavior. E.g. one part of application used during one
phase, another part is used during another phase, etc.
You can find more details in the help topic for li1040 linker error
message."
Hope this helps Everyone. Creating an external segment and using this method
worked for me.
-----Original Message-----
From: adsp@adsp... [mailto:adsp@adsp...]On Behalf Of Jon
Harris
Sent: 18-Aug-05 9:23 AM
To: adsp@adsp...
Subject: Re: [adsp] 21065L w C code... seg_pmco full of libc.dlb,
libio.dlb and source I'm assuming you are using VDSP++ 4.0. If so, under Project
Options-Elimination, make sure you have Eliminate unused objects checked.
This
should remove any functions that are included in a library but not actually
called. It also removes variables that are deemed unused, which can
sometimes
cause problems with debuggig, so be careful.
--- mattw_024 <weberms@webe...> wrote:
> Hello Everyone,
>
> Just had a question for you relating to mapping my code into memory.
> Previously I had developed my code on the 21060 because it had more
> internal memory space for my code, however now that I have finished
> developing the code I wanted to put it into the 21065L which is the
> processor I need to use.
>
> This is my problem: the seg_pmco section contains 0x3c62 words that
> are
> not being mapped to memory due to the code being too large to fit.
> (Obviously because there is so much code, just making the segment
> larger
> will not work because there isnt that much internal memory to work
> with). I had a similar problem in seg_dmda, which I solved by moving
> some of the data to an external segment I created (in the ldf). I
> attempted to do the same thing with the seg_pmco, but with no success.
> This was because I have libio.dlb and libc.dlb in that segment, which
> are very large, along with a lot of other code which is specific to my
> program. libc.dlb and libio.dlb do not appear to be movable, when
> using
> the expert linker. I tried to use the elfar utility to dissassemble
> those libraries so I could move the *.obj files individually. Im
> still
> working on that, but is there any better way to do this? Would using
> memory overlays be helpful? I'm a little unclear as to how I should be
> treating this, and Im sure there are many other pople who have run
> into
> similar problems since those *.dlb's are quite large. Let me know if
> using the elfar utlity to break those up into *.obj's is the way to
> go... if not what do you suggest? Thanks a lot.
>
> Sincerely,
>
> Matt Weber
__________________________________________________
