View previous topic :: View next topic |
Author |
Message |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Sat Jan 21, 2006 7:21 am Post subject: Internal "messaging" |
|
|
Linking of elf files involves many different settings and options, most of which in theory can be specified on the command line to a linking tool. Some of these will be elf specific, some will be generic.
What I'm wondering is what's the best way to get them from the tool to the ELFBinary class (that'll handle the hard work). And it should be a solution that is common through DDL.
The "easiest" solution is just setting up a lot of constants in a DDLConstants.d file, possibly longs, and make them and/or-able all over the line, so we could just have an setFlags(long flags), then each class could handle the flags relevant for them. But I don't think that would give us enough flags in the long run.
But having setThisAndThat methods for all options sound overkill.
I guess you all understand what I get at. What's the best solution? Flags might be grouped of course, but then it is the question about what to group with what. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Sat Jan 21, 2006 8:11 am Post subject: |
|
|
Could you use DDL/Bless attributes? |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Sat Jan 21, 2006 8:18 am Post subject: |
|
|
kris wrote: | Could you use DDL/Bless attributes? |
I suppose you are meaning stuff like
Code: |
char [][char[]] attrs;
attrs["target"] = "ELF";
setAttrs(attrs);
|
Yes, I think that might be a better solution. Thinking about it, it's already halfway in, I've just not given it thought. My bad. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Sat Jan 21, 2006 9:17 am Post subject: |
|
|
hmm, how should we document available attributes?
They are not code entities in themselves, just strings, but we don't want a plethora of strings running around, so we should have a "library" of attributes and their allowed values. We could put them at the wiki, of course.
And how explicit should they be in their naming?
Is attrs["debug"] = "on"; good enough? |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Sat Jan 21, 2006 10:12 am Post subject: |
|
|
I admit, it's not exactly where you'd expect in the Wiki, but it is there.
http://trac.dsource.org/projects/ddl/wiki/Reference/ABI/DDL#AttributeMetadata
There's absolutely no reason why the attributes have to be stored in the .ddl wrapper. You can create as many as you want internally from your library class.
Just make all your attributes start with "elf." and you'll be collision free with all the other supported ddl types. If storing things as strings becomes a problem, let me know and I'll see about concocting a more binary-friendly solution. _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Sat Jan 21, 2006 10:47 am Post subject: |
|
|
pragma wrote: | I admit, it's not exactly where you'd expect in the Wiki, but it is there.
http://trac.dsource.org/projects/ddl/wiki/Reference/ABI/DDL#AttributeMetadata
There's absolutely no reason why the attributes have to be stored in the .ddl wrapper. You can create as many as you want internally from your library class.
Just make all your attributes start with "elf." and you'll be collision free with all the other supported ddl types. If storing things as strings becomes a problem, let me know and I'll see about concocting a more binary-friendly solution. |
Hmm, I think the string thingy is working nice. I'm currently not needing to store any of them, just for passing around settings.
Some of the attributes I need, will be broader than just elf, it's those I'm thinking most about, for example target platform (processor, binary type, os, etc), but I suppose the std. namespace is usable. I'll look at it, and try to fit it in and document it where necessary. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Sun Jan 22, 2006 5:21 am Post subject: |
|
|
That's what they're there for. You're right on the money for using "std.platform" or "std.arch" for the platform/processor specific stuff. These should probably find their way into COFF and OMF too while we're at it. _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Sat Feb 04, 2006 10:41 am Post subject: |
|
|
Hmm, I'm starting to think that a DDL app should have a global attributes library. Maybe that's already the plan, I just haven't seen it
What I'm thinking, is the line
Code: |
Attributes globals; // or attrs
|
in ddl.Attributes or ddl.Globals or whatever.
Thus if you need to set some attribute that is needed somewhere else, and you otherwise don't have an easy way to pass it to that class, it could just import ddlGlobals and have globals accessible as a global. Thus classes only need to keep attributes if they otherwise would conflict with the globals, or are only needed internally in the module/class.
AFAICS, the getAttrs in DynamicLibrary is for getting attributes from loaded libs and such, yes? In which case it isn't what I'm thinking about, since I'm blabbering about attrs for apps compiled against DDL, like our utils. The attrs from getAttrs could still be stored in globals, though. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Sat Feb 04, 2006 5:19 pm Post subject: |
|
|
larsivi wrote: | AFAICS, the getAttrs in DynamicLibrary is for getting attributes from loaded libs and such, yes? In which case it isn't what I'm thinking about, since I'm blabbering about attrs for apps compiled against DDL, like our utils. The attrs from getAttrs could still be stored in globals, though. |
You're correct in second-guessing yourself: the attributes are strictly a metadata facility to supplement library loading. Moreover, they're there to support things like versioning, licensing, copyright - stuff that isn't typically covered in library binaries, or isn't covered uniformly.
Now there's no reason why it can't be used for addtional purposes. Just keep in mind that if its not coded for explicitly within this project, you can't make any guarantee for the presence of such an attribute. Just grep the project for "std.version" and you'll see what I"m talking about.
As for 'global' attributes as applied to compiled apps and such - I do have a getAttributes() coded into the DynamicModule base class. When static initalization of associative arrays becomes available, it should fill in most of the other use cases nicely, yes? _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Sun Feb 05, 2006 3:23 am Post subject: |
|
|
pragma wrote: | larsivi wrote: | AFAICS, the getAttrs in DynamicLibrary is for getting attributes from loaded libs and such, yes? In which case it isn't what I'm thinking about, since I'm blabbering about attrs for apps compiled against DDL, like our utils. The attrs from getAttrs could still be stored in globals, though. |
You're correct in second-guessing yourself: the attributes are strictly a metadata facility to supplement library loading. Moreover, they're there to support things like versioning, licensing, copyright - stuff that isn't typically covered in library binaries, or isn't covered uniformly.
Now there's no reason why it can't be used for addtional purposes. Just keep in mind that if its not coded for explicitly within this project, you can't make any guarantee for the presence of such an attribute. Just grep the project for "std.version" and you'll see what I"m talking about.
As for 'global' attributes as applied to compiled apps and such - I do have a getAttributes() coded into the DynamicModule base class. When static initalization of associative arrays becomes available, it should fill in most of the other use cases nicely, yes? |
Ah, yes, badly explained from me. I'm talking about attributes that would affect internal operation in DDL, for example the removal of duplicates during linking. This attribute could be set by a command line parameter to a link tool, or through code for some application needing this functionality. There are several such attributes that affect operation within the ELFBinary, the most important one is how to handle the loaded object files, create executable, shared library or other stuff. And I find it very cumbersome to pass these attributes/settings around via DynamicLibrary. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Sun Feb 05, 2006 8:49 am Post subject: |
|
|
larsivi wrote: | Ah, yes, badly explained from me. I'm talking about attributes that would affect internal operation in DDL, for example the removal of duplicates during linking. This attribute could be set by a command line parameter to a link tool, or through code for some application needing this functionality. There are several such attributes that affect operation within the ELFBinary, the most important one is how to handle the loaded object files, create executable, shared library or other stuff. And I find it very cumbersome to pass these attributes/settings around via DynamicLibrary. |
Okay, I think I understand where you're coming from now. So I understand, are you finding the limitations of the DDL design while trying to compose your linker utility? That makes sense since it was never designed with a traditional linker in mind.
In such a case, you're probably struggling to get the actual data that backs up any given symbol (the various virtual segments for each lib and whatnot). Would adding a getSymbolData() method to DynamicModule and DynamicLibrary be enough? Also, how about a getFixups() method?
I think with something like that, a static linker would be much easier to compose. _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Sun Feb 05, 2006 9:19 am Post subject: |
|
|
pragma wrote: | larsivi wrote: | Ah, yes, badly explained from me. I'm talking about attributes that would affect internal operation in DDL, for example the removal of duplicates during linking. This attribute could be set by a command line parameter to a link tool, or through code for some application needing this functionality. There are several such attributes that affect operation within the ELFBinary, the most important one is how to handle the loaded object files, create executable, shared library or other stuff. And I find it very cumbersome to pass these attributes/settings around via DynamicLibrary. |
Okay, I think I understand where you're coming from now. So I understand, are you finding the limitations of the DDL design while trying to compose your linker utility? That makes sense since it was never designed with a traditional linker in mind.
In such a case, you're probably struggling to get the actual data that backs up any given symbol (the various virtual segments for each lib and whatnot). Would adding a getSymbolData() method to DynamicModule and DynamicLibrary be enough? Also, how about a getFixups() method?
I think with something like that, a static linker would be much easier to compose. |
Hmm, that'll probably help with the dynamic linking, but not the linker tool AFAICS at the moment (an executable is more or less a reordering of the sections in the object files, with some additional headers/tables created. The symbols themselves ain't that much of a problem (I hope)).
But I'll look into that as well. I'll probably just plug at it, and then try to fit it into the existing API as much as possible ![Smile](images/smiles/icon_smile.gif) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|