Index
> Compiler Internals > [request] Custom MS-COFF symbols |
| Author |
|
|
Tomasz Grysztar 17 Mar 2007, 14:05
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"?)
|
|||
17 Mar 2007, 14:05 |
|
|
vid 17 Mar 2007, 14:17
you see, you should have used symbolic structure offsets and lengths
 
i think general directive to create any type of symbol would be better
unfortunatelly, i still don't understand how formatter works and what things are passed to formatter 
if there is no way, i would prefer something like Code: public static 10 as "@xyz" |
|||
|
17 Mar 2007, 14:17 |
|
|
Tomasz Grysztar 17 Mar 2007, 14:32
vid wrote: if there is no way, i would prefer something like This also isn't possible with current formatter. Only: Code: a=10 public static a as "@xyz" |
|||
|
17 Mar 2007, 14:32 |
|
|
vid 17 Mar 2007, 14:35
could you explain more on how formatter works and why is it a problem, please?
|
|||
|
17 Mar 2007, 14:35 |
|
|
Tomasz Grysztar 17 Mar 2007, 15:29
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). |
|||
|
17 Mar 2007, 15:29 |
|
|
vid 17 Mar 2007, 16:07
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) 
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? |
|||
|
17 Mar 2007, 16:07 |
|
|
Tomasz Grysztar 17 Mar 2007, 16:44
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. |
|||
|
17 Mar 2007, 16:44 |
|
|
vid 18 Mar 2007, 19:12
Tomasz Grysztar 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. 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. 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' Code: x = expression public x as 'XXX' |
|||
|
18 Mar 2007, 19:12 |
|
|
Tomasz Grysztar 18 Mar 2007, 21:37
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. |
|||
|
18 Mar 2007, 21:37 |
|
|
vid 19 Mar 2007, 00:17
it's a matter of point of view
how do you feel about implementing my original suggestion - symbol directive? |
|||
|
19 Mar 2007, 00:17 |
|
< Last Thread | Next Thread > |
Forum Rules:
|