Re: [AD] dat2s bug

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> I think the cleanest approach for a robust fix is to prevent dat2s from
> emitting any library symbol in the assembly file and to defer the linking
> to _construct_datafile() at runtime. I'm working on a patch.

Attached is a first version that implements this approach. The only hurdle I
was faced with was that _construct_datafile() can't now be invoked more than
once on a given datafile: this would be automatically guaranteed if
_construct_datafile() was a pure constructor function, but it isn't since
fixup_datafile() calls it.

So I needed a method to mark the datafile as already constructed in the
assembly file. I thought of two solutions:
- adding a flag before the start of the DATAFILE array in the assembly file,
- using the 'size' field of the last member of the DATAFILE array (the one
tagged with DAT_END).

I chose the former, because the latter would require to walk down twice more
the DATAFILE array (when fixup_datafile is used). But that's admittedly not
very elegant and the latter solution could be more convenient (see below).

This patch breaks of course the ABI for platforms that support dynamic
builds (and for which dat2s already works: Linux, BeOS ?), so it is only for
the 4.1.x series. It also breaks Laurence's dat2c (possibly in a major way,
in which case the latter solution would be far less intrusive).

Laurence, what do you think about it ? And would it not be time to merge
your dat2c code into the distribution ?

- Eric

Attachment: dat2s.zip
Description: Zip compressed data