Re: [Nasm-devel] Override extern with global for header files

[H. P. A. <hp...@zy...>]

On 09/28/2014 04:39 PM, Lars Maier wrote:
> Hello at all,
> I'm working a lot with nasm and after a while I created a little library
> I use in all nasm-Projects. Therefor some header files are very useful
> (e.g. defining constants and externs).
> I don't want to mess around with some macros for simple imports. I
> thought of a c-prototype-like symbol definition for externs. What if a
> defined extern could be redefined as global.
> 
> I had a look at the source code and found two possible solutions:
> 
> 1.) see http://repo.or.cz/w/nasm.git/blob/HEAD:/labels.c#l278
> one could allow in line 294, that externs could be redefined as global.
> By a quick look, I think, that this wouldn't be a problem for the
> labelmanager. find_lable simply returns the label and define_lable would
> refill it with the global singal data. The bigger problem is the ofmt,
> because the ofmt->symdef is explicitly called _once_ for each symbol.
> Looking at, for example, the objobj.c you can see, that symbols are
> stored in linked lists and there is no check for double names or
> something like that. -> Bad solution (update all objformats, looping
> through list for each symbol)
> 
> 2.) if somehow possible, and symbols do not need to passed to the ofmt
> directly after they were found (somehow context dependend), then you
> could buffer the extern symbols until the whole analysis is ready. every
> extern symbol that was not replaced by a global would then be passed the
> the ofmt. exclude extern symbols at
> http://repo.or.cz/w/nasm.git/blob/HEAD:/labels.c#l327 and introduce a
> new function, that loops through all symbols and passes the missing
> externs to the ofmt. call the function in the main function at the right
> place (maybe here: http://repo.or.cz/w/nasm.git/blob/HEAD:/nasm.c#l466).
> 
> I would love to from you!
> Lars
> 

It would seem like a reasonable thing to do, and is obviously use in C
to good effect.  I agree that option 2 would by far be preferable, and
it looks like you have thought of this a lot.  Would you be willing to
write up a patch?

	-hpa