Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » DSDP - Real-Time Software Components (RTSC) » link filter
link filter [message #749897] Tue, 25 October 2011 13:59 Go to next message
Patrick Geremia is currently offline Patrick GeremiaFriend
Messages: 79
Registered: July 2009
Member
I am in the process of creating an ARM executable which uses shared
libraries.

The problem right now is that when linking a generated linker script
(.xdl) is used. This scripts refers to the libraries using absolute path.
Since I cross compile and the executable will run on the target hw I
cannot use this executable as it has links to path on my host platform.

I basically need to generate a command line like below :

lnk .... -Lpath/to/lib/A -Lpath/to/lib/B -llibA -llibB -Wl,-rpath
-Wl,/opt/bin/oam/lib

instead of

lnk .... -Wl,-T,package/cfg/exe/somefile.xdl ...

I tried to use the filter for the link function but the xdl file is
generated after the filter is invoked and I therefore cannot access it.

Any idea how to bring this forward?
Re: link filter [message #753354 is a reply to message #749897] Wed, 26 October 2011 19:38 Go to previous messageGo to next message
Sasha Slijepcevic is currently offline Sasha SlijepcevicFriend
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 Go to previous messageGo to next message
Dave Russo is currently offline Dave RussoFriend
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 Go to previous messageGo to next message
Patrick Geremia is currently offline Patrick GeremiaFriend
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 Go to previous messageGo to next message
Patrick Geremia is currently offline Patrick GeremiaFriend
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 Go to previous messageGo to next message
Patrick Geremia is currently offline Patrick GeremiaFriend
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 Go to previous message
Dave Russo is currently offline Dave RussoFriend
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 ...";
}
Previous Topic:How to get *Multiple* libraries at getLibs handler
Next Topic:symbolic links to data not physically present during the release process are ignored in the released
Goto Forum:
  


Current Time: Thu Oct 10 14:04:48 GMT 2024

Powered by FUDForum. Page generated in 0.03647 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top