Home » Archived » DSDP - Real-Time Software Components (RTSC) » link filter
|
| Re: link filter [message #753354 is a reply to message #749897] |
Wed, 26 October 2011 19:38   |
 Sasha Slijepcevic
Messages: 115
Registered: July 2009 |
Senior Member |
|
|
Patrick,
is this a one-time project for one application or you need something that you will use for many applications. If it's the former, you should consider the parameter Program.linkTemplate. You'll have to create a new file, copy a content of the actual template that you are using, most likely it is gnu/targets/arm/linkcmd.xdt, and set Program.linkTemplate to that new file. Then inside that file you'll see the loop that generates the paths to libraries, and in there you'll need to change library paths and add additional linker command line options.
This solution requires that you add Program.linkTemplate assignment to the applications config script, and it's not very appealing if you have to do it for many applications.
I don't really think you can solve this problem using only target filters because at the build time, when the filters are running, you can't possibly know which libraries to add. You have to have some code running at the configuration time, and in my proposal above, it's the template. There could be some other hook you could use at the config time, but it boils down to a solution similar to the one I proposed.
Let me know if Program.linkTemplate does not work for you.
|
|
|
| Re: link filter [message #754039 is a reply to message #753354] |
Mon, 31 October 2011 14:55 |
Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
On 10/26/2011 12:39 PM, Sasha Slijepcevic wrote:
> This solution requires that you add Program.linkTemplate assignment
> to the applications config script, and it's not very appealing if you
> have to do it for many applications.
>
[snip]
> I don't really think you can solve this problem using only target
> filters because at the build time, when the filters are running, you
> can't possibly know which libraries to add.
For what it's worth, you can get a list of all libraries from the
ITargetFilter. We currently do this for our Coverity target filter, for
example.
In that case, we use ITargetFilter.getGenTab() and supply a template
that is expanded, at config time, into a shell script that can be run to
analyze the executable _as a whole_. Since this template is run during
the generation phase, it is also possible to simply generate the list of
libraries to link with.
So ... if, during the build phase, you use ITargetFilter.link() to
change the link command to use this list of libraries (e.g., replace it
with a a shell script that "wraps" the link command into a command that
reads the library list), you should be able to manage the entire link
application link.
While I doubt this is a better approach than Sasha's original suggestion
(which is much less complicated), it is similar to what we do with the
Coverity filter.
|
|
|
| Re: link filter [message #754455 is a reply to message #754039] |
Wed, 02 November 2011 15:14 |
Patrick Geremia
Messages: 79
Registered: July 2009 |
Member |
|
|
Thanks for your replies.
I have now implemented a tactical workaround (link filter to remove xdl
file from command line and explict list of libraries in config.bld).
I will look at your proposals later and will sure come back to you.
----------------------------------------------------------------------
From : dave russo <d-russo@ti.com>
Date : Mon Oct 31 2011 15:55:14 GMT+0100 (CET)
> On 10/26/2011 12:39 PM, Sasha Slijepcevic wrote:
> > This solution requires that you add Program.linkTemplate assignment
> > to the applications config script, and it's not very appealing if you
> > have to do it for many applications.
> >
> [snip]
> > I don't really think you can solve this problem using only target
> > filters because at the build time, when the filters are running, you
> > can't possibly know which libraries to add.
>
> For what it's worth, you can get a list of all libraries from the
> ITargetFilter. We currently do this for our Coverity target filter, for
> example.
>
> In that case, we use ITargetFilter.getGenTab() and supply a template
> that is expanded, at config time, into a shell script that can be run to
> analyze the executable _as a whole_. Since this template is run during
> the generation phase, it is also possible to simply generate the list of
> libraries to link with.
>
> So ... if, during the build phase, you use ITargetFilter.link() to
> change the link command to use this list of libraries (e.g., replace it
> with a a shell script that "wraps" the link command into a command that
> reads the library list), you should be able to manage the entire link
> application link.
>
> While I doubt this is a better approach than Sasha's original suggestion
> (which is much less complicated), it is similar to what we do with the
> Coverity filter.
|
|
|
| Re: link filter [message #879176 is a reply to message #753354] |
Wed, 30 May 2012 17:07 |
Patrick Geremia
Messages: 79
Registered: July 2009 |
Member |
|
|
I started playing around and got into problems quite quickly
I added the following in my config.bld
>>>>
/* get the base directory for current package */
var pkgDir = xdc.getPackageBase(Pkg.name);
pkgDir=pkgDir.replace(/\\/g, "/");
var prog = xdc.module('xdc.cfg.Program');
prog.linkTemplate = pkgDir + "linkcmd.xdt";
<<<<<
and got the following error (linkcmd.xdt comes from the xdc installation)
js:
"/data/wisap/tools/ti/sc_mcsdk/2_0_0_6/xdctools_3_22_04_46/packages/xdc/cfg/package.xs",
line 47: TypeError: Cannot find function getSectMap in object function
Program() {
[native code, arity=2]
}
..
What I am trying to do is to add a static library after the xdl and not
before the xdc on the linker command line i.e.
$somedir/ossasn1/lib/libasn1code.a $somedir/ossasn1/lib/libosstoed.a
using the option gnuLinkOpts (see below extract from config.bld) puts
them *before* the xdl inclusion on the command line and this is why I
was thinking about the link template.
>>>>>
if (gnuCgtDir)
{
gnu.profiles[pkgName + "_release_wcdma"] =
{
compileOpts:
{
copts: "-O2 ",
incs: gnuIncsCommon,
defs: gnuDefsCommon + " -DBOAM_WCDMA -DBOAM_BUILD ",
},
linkOpts: gnuLinkOpts
};
if (debugEnableFlag)
{
gnu.profiles[pkgName + "_debug_wcdma"] = gnu.profiles[pkgName +
"_release_wcdma"];
gnu.profiles[pkgName + "_debug_wcdma"].compileOpts.copts="-g ";
}
build.targets.$add(gnu);
}
<<<<<
Any idea?
----------------------------------------------------------------------
From : Sasha Slijepcevic <forums-noreply@xxxxxxxx>
Date : Wed Oct 26 2011 21:39:02 GMT+0200 (CEST)
> Patrick,
> is this a one-time project for one application or you need something
> that you will use for many applications. If it's the former, you should
> consider the parameter
> http://rtsc.eclipse.org/cdoc-tip/xdc/cfg/Program.html#link.Template.
> You'll have to create a new file, copy a content of the actual template
> that you are using, most likely it is gnu/targets/arm/linkcmd.xdt, and
> set Program.linkTemplate to that new file. Then inside that file you'll
> see the loop that generates the paths to libraries, and in there you'll
> need to change library paths and add additional linker command line
> options.
> This solution requires that you add Program.linkTemplate assignment to
> the applications config script, and it's not very appealing if you have
> to do it for many applications.
>
> I don't really think you can solve this problem using only target
> filters because at the build time, when the filters are running, you
> can't possibly know which libraries to add. You have to have some code
> running at the configuration time, and in my proposal above, it's the
> template. There could be some other hook you could use at the config
> time, but it boils down to a solution similar to the one I proposed.
> Let me know if Program.linkTemplate does not work for you.
|
|
|
| Re: link filter [message #879179 is a reply to message #879176] |
Wed, 30 May 2012 17:12 |
Patrick Geremia
Messages: 79
Registered: July 2009 |
Member |
|
|
ok after reading the doc one more time.
using
Program.linkTemplate = pkgDir + "linkcmd.xdt";
instead of
var prog = xdc.module('xdc.cfg.Program');
prog.linkTemplate = pkgDir + "linkcmd.xdt";
Stay tuned.
----------------------------------------------------------------------
From : Patrick Geremia <p-geremia@xxxxxxxx>
Date : Wed May 30 2012 19:07:51 GMT+0200 (CEST)
> I started playing around and got into problems quite quickly
> I added the following in my config.bld
>
>>>>>
> /* get the base directory for current package */
> var pkgDir = xdc.getPackageBase(Pkg.name);
> pkgDir=pkgDir.replace(/\\/g, "/");
>
> var prog = xdc.module('xdc.cfg.Program');
> prog.linkTemplate = pkgDir + "linkcmd.xdt";
> <<<<<
>
> and got the following error (linkcmd.xdt comes from the xdc installation)
>
> js:
> "/data/wisap/tools/ti/sc_mcsdk/2_0_0_6/xdctools_3_22_04_46/packages/xdc/cfg/package.xs",
> line 47: TypeError: Cannot find function getSectMap in object function
> Program() {
> [native code, arity=2]
> }
> .
>
> What I am trying to do is to add a static library after the xdl and not
> before the xdc on the linker command line i.e.
> $somedir/ossasn1/lib/libasn1code.a $somedir/ossasn1/lib/libosstoed.a
>
> using the option gnuLinkOpts (see below extract from config.bld) puts
> them *before* the xdl inclusion on the command line and this is why I
> was thinking about the link template.
>
>>>>>>
> if (gnuCgtDir)
> {
> gnu.profiles[pkgName + "_release_wcdma"] =
> {
> compileOpts:
> {
> copts: "-O2 ",
> incs: gnuIncsCommon,
> defs: gnuDefsCommon + " -DBOAM_WCDMA -DBOAM_BUILD ",
> },
> linkOpts: gnuLinkOpts
> };
> if (debugEnableFlag)
> {
> gnu.profiles[pkgName + "_debug_wcdma"] = gnu.profiles[pkgName +
> "_release_wcdma"];
> gnu.profiles[pkgName + "_debug_wcdma"].compileOpts.copts="-g ";
> }
> build.targets.$add(gnu);
> }
> <<<<<
>
> Any idea?
>
>
> ----------------------------------------------------------------------
> From : Sasha Slijepcevic <forums-noreply@xxxxxxxx>
> Date : Wed Oct 26 2011 21:39:02 GMT+0200 (CEST)
>
>
>> Patrick,
>> is this a one-time project for one application or you need something
>> that you will use for many applications. If it's the former, you should
>> consider the parameter
>> http://rtsc.eclipse.org/cdoc-tip/xdc/cfg/Program.html#link.Template.
>> You'll have to create a new file, copy a content of the actual template
>> that you are using, most likely it is gnu/targets/arm/linkcmd.xdt, and
>> set Program.linkTemplate to that new file. Then inside that file you'll
>> see the loop that generates the paths to libraries, and in there you'll
>> need to change library paths and add additional linker command line
>> options.
>> This solution requires that you add Program.linkTemplate assignment to
>> the applications config script, and it's not very appealing if you have
>> to do it for many applications.
>>
>> I don't really think you can solve this problem using only target
>> filters because at the build time, when the filters are running, you
>> can't possibly know which libraries to add. You have to have some code
>> running at the configuration time, and in my proposal above, it's the
>> template. There could be some other hook you could use at the config
>> time, but it boils down to a solution similar to the one I proposed.
>> Let me know if Program.linkTemplate does not work for you.
|
|
|
| Re: link filter [message #880813 is a reply to message #879176] |
Sun, 03 June 2012 03:28 |
Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
On 5/30/2012 10:07 AM, Patrick Geremia wrote:
> I started playing around and got into problems quite quickly
> I added the following in my config.bld
>
>>>>>
> /* get the base directory for current package */
> var pkgDir = xdc.getPackageBase(Pkg.name);
> pkgDir=pkgDir.replace(/\\/g, "/");
>
> var prog = xdc.module('xdc.cfg.Program');
> prog.linkTemplate = pkgDir + "linkcmd.xdt";
> <<<<<
The problem is that config.bld is executed in the "build model" and not
the "config model"; scripts running in the build model configure targets
and specify the contents of the package (libraries, executables, etc.)
and the result of these scripts is the package.mak makefile. The the
xdc.cfg.Program module is part of the "config model" and is initialized
only as part of application .cfg scripts. So ...
The statements above need to be added to your application's .cfg script
rather than config.bld.
Alternatively, you can specify a link template from your package.bld
script (which is executed in the build model) by setting the
linkTemplate property of the executable specified by
Pkg.addExecutable(). For example, in your package.bld script
Pkg.addExecutable("myExe", targ, targ.platform, {
linkTemplate: pkgDir + "linkcmd.xdt"
});
See
http://rtsc.eclipse.org/cdoc-tip/index.html#xdc/bld/PackageContents.html#add.Executable
and
http://rtsc.eclipse.org/cdoc-tip/index.html#xdc/bld/Executable.html#.Attrs.
>
> What I am trying to do is to add a static library after the xdl and not
> before the xdc on the linker command line i.e.
> $somedir/ossasn1/lib/libasn1code.a $somedir/ossasn1/lib/libosstoed.a
>
> using the option gnuLinkOpts (see below extract from config.bld) puts
> them *before* the xdl inclusion on the command line and this is why I
> was thinking about the link template.
>
>>>>>>
> if (gnuCgtDir)
> {
> gnu.profiles[pkgName + "_release_wcdma"] =
> {
> compileOpts:
> {
> copts: "-O2 ",
> incs: gnuIncsCommon,
> defs: gnuDefsCommon + " -DBOAM_WCDMA -DBOAM_BUILD ",
> },
> linkOpts: gnuLinkOpts
> };
> if (debugEnableFlag)
> {
> gnu.profiles[pkgName + "_debug_wcdma"] = gnu.profiles[pkgName +
> "_release_wcdma"];
> gnu.profiles[pkgName + "_debug_wcdma"].compileOpts.copts="-g ";
> }
> build.targets.$add(gnu);
> }
> <<<<<
>
> Any idea?
You can try configuring the target's lnkOpts configuration parameter.
This allows you to place options at the end of the link line _but_ it
applies to _all_ profiles of the target. From your example, you are
creating package-specific profiles so this may not be a problem.
Since the config.bld script is re-run for each package, you can simply
set the options gnu.lnkOpts.suffix as appropriate based on the package
name. For example:
if (Pkg.name == "my.pkg") {
gnu.lnkOpts.suffix= "$somedir/ossasn1/lib/libasn1code.a ...";
}
|
|
|
Goto Forum:
Current Time: Thu Apr 25 08:24:02 GMT 2024
Powered by FUDForum. Page generated in 0.03513 seconds |
] 
Search
Help
Register
Login
Home
