flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > [request] Custom MS-COFF symbols

Author
Thread Post new topic Reply to topic
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Would it be possible to add possiblity of defining custom symbols for MS-COFF format? Type, class, segment and address could be specified directly.

It is needed to create SAFESEH object for example.

It could even allow producing some symbolic info with macros.
Post 17 Mar 2007, 13:44
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
There's no simple method to add such general feature to the current formatter architecture. Though it's possible to smuggle an additional bit or two, thus I'm thinking about how to allow exporting static symbols, perhaps I just need a good syntax for it (something like "public a:static dword"?)
Post 17 Mar 2007, 14:05
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
you see, you should have used symbolic structure offsets and lengths Razz Wink

i think general directive to create any type of symbol would be better Wink

unfortunatelly, i still don't understand how formatter works and what things are passed to formatter Sad

if there is no way, i would prefer something like
Code:
public static 10 as "@xyz"    
Post 17 Mar 2007, 14:17
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
vid wrote:
if there is no way, i would prefer something like
Code:
public static 10 as "@xyz"    

This also isn't possible with current formatter. Only:
Code:
a=10
public static a as "@xyz"    
Post 17 Mar 2007, 14:32
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
could you explain more on how formatter works and why is it a problem, please?
Post 17 Mar 2007, 14:35
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
All the object formatters use a sequence of "formatter objects" stored in additional memory block. This sequence contains section/extrn/public symbols (as so it is later converted into symbol table appropriate for given object) and has a strict common format right now, for COFF and ELF formatters in all flavors (note that PUBLIC/EXTRN are handled exactly the same way for all formats, the difference is only at final stage, when this sequence is converted into symbol table of a given format).
The PUBLIC entries in that sequence contain the name of symbol (the one from quoted string after the AS operator, parser converts PUBLIC directive so that it always contains AS clause - it was needed, because at assembly stage only the quoted strings are preserved) and the pointer to symbol that you are exporting - so you cannot export just a value, you always export a symbol existing in fasm's symbol space.

Thus I'd prefer the solution like with "static" keyword, as it would just be a flag for fasm's symbol table entry itself, which would then be converted into appropriate symbol table values for various object formats (COFF, ELF, and planned Mach-O perhaps).
Post 17 Mar 2007, 15:29
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
I think you should extend formatter objects structure to allow value too. Anyway, for static symbols it seems natural to pass value, not another symbol. Along with this, there could be also symbol class and type.

I understand it's more work for you, but i think it's worth and is a good upgrade of internal design. And i think this wouldn't be very much coding needed (feel free to correct me) Smile

PS: With current design, you could allow public 10 as 'something' by making parser silently declare and use constant for you. Not sure, it might cause problems with displaying error when value is invalid?
Post 17 Mar 2007, 16:07
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
vid wrote:
Anyway, for static symbols it seems natural to pass value, not another symbol.

What is this opinion based upon?

Quote:
I understand it's more work for you, but i think it's worth and is a good upgrade of internal design.

I like the current universal approach, a different object formats use exactly the same internal structures (the only difference is the availability of some section flags), so that's not really an "upgrade" I would consider a nice design.
Extending it for all possible objects at the same time (with option of signalizing an error when given format doesn't allow given kind of symbol - just like it's with section flags) seems much more acceptable.

PS. In earliest versions of fasm PUBLIC/EXTRN were called EXPORT/IMPORT. Thus the philosophy that with PUBLIC you export something that you have defined in your code - label or numeric constant.

Quote:
PS: With current design, you could allow public 10 as 'something' by making parser silently declare and use constant for you. Not sure, it might cause problems with displaying error when value is invalid?

The parser cannot define a value for symbol, as the symbol must get defined correctly in each pass, otherwise it won't work.
Post 17 Mar 2007, 16:44
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Tomasz Grysztar wrote:
vid wrote:
Anyway, for static symbols it seems natural to pass value, not another symbol.

What is this opinion based upon?

because static symbols are used for declaring symbol with any value, not just pointers to code. As an example, see "@feat.00" with value 1.

Quote:
Extending it for all possible objects at the same time (with option of signalizing an error when given format doesn't allow given kind of symbol - just like it's with section flags) seems much more acceptable.
i agree

Quote:
The parser cannot define a value for symbol, as the symbol must get defined correctly in each pass, otherwise it won't work.

you didn't comprehend me. I meant that parsing
Code:
public expression as 'XXX'    
would be parsed to equivalent of
Code:
x = expression
public x as 'XXX'    
. Just an idea for dirty workaround.
Post 18 Mar 2007, 19:12
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
vid wrote:
because static symbols are used for declaring symbol with any value, not just pointers to code. As an example, see "@feat.00" with value 1.

Same argument would apply to global absolute values. The point is that you just export a symbol that is defined in your code. To export a symbol with absolute value, you just define one with absolute value (like numerical constant) and export it.
Post 18 Mar 2007, 21:37
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
it's a matter of point of view

how do you feel about implementing my original suggestion - symbol directive?
Post 19 Mar 2007, 00:17
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
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
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.