FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Internal "messaging"

 
Post new topic   Reply to topic     Forum Index -> DDL - D Dynamic Libraries
View previous topic :: View next topic  
Author Message
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sat Jan 21, 2006 7:21 am    Post subject: Internal "messaging" Reply with quote

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
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Sat Jan 21, 2006 8:11 am    Post subject: Reply with quote

Could you use DDL/Bless attributes?
Back to top
View user's profile Send private message
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sat Jan 21, 2006 8:18 am    Post subject: Reply with quote

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
View user's profile Send private message
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sat Jan 21, 2006 9:17 am    Post subject: Reply with quote

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
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Sat Jan 21, 2006 10:12 am    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sat Jan 21, 2006 10:47 am    Post subject: Reply with quote

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
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Sun Jan 22, 2006 5:21 am    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sat Feb 04, 2006 10:41 am    Post subject: Reply with quote

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 Smile

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
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Sat Feb 04, 2006 5:19 pm    Post subject: Reply with quote

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. Smile

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
View user's profile Send private message Yahoo Messenger
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sun Feb 05, 2006 3:23 am    Post subject: Reply with quote

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. Smile

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
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Sun Feb 05, 2006 8:49 am    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sun Feb 05, 2006 9:19 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> DDL - D Dynamic Libraries All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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