[fpc-devel] symify.pp broken

[Tomas Hajny]

On Mon, April 7, 2008 13:23, Robert Riebisch wrote:
> Peter Vreman wrote
>> >> Runtime error 255 at $000020AC
>> >>   $000020AC of ?·?
>> >>   $000020B8 of ?·?
>> >>   $000020C9 of ?·?
>> >>   $00002098 of ?·?
>> >>
>> >> Looks like the lineinfo unit is also broken.
>> >
>> > But it works for old FPC versions 2.0.4 (dos204.zip), 2.2.0 (my own
>> > build), or 2.2.1 (fpc-2.2.1.go32v2.zip).
>>
>> Parts of the lineinfo related code are rewritten in 2.3.1. There is no
>> active development done on
>> go32v2. So it can be that svn code is broken go32v2.
>
> I identified the problem now: "secofs" value returned by function
> "FindSectionCoff" in file "exeinfo.pp" is always 2,048 bytes too small.
> 2,048 (or $800) is the size of the go32 EXE stub.
>
> I failed to find an elegant solution, that doesn't break PE32 or
> PE32PLUS. Maybe somebody else, who's more familiar with FPC's source
> code, could fix this?! Of course, I could assist as a tester.

I looked at it briefly, adding an offset of 2048 bytes is quite easy, one
possible solution might be extending TExeFile record with yet another
field (e.g. DebugOffset) and initialize this variable to 0 in all Open*
functions except OpenGo32Coff, which should check for "go32stub" string at
e_cparhdr * 16 (count of paragraphs in header * size of a paragraph = 10h)
which is not done while reading but it supposedly should according to
DJGPP sources for stubedit and set the value to 2048 in that case. BTW,
this value of 2048 is already used there, it should be replaced with a
constant if we go this direction.

However, I can't believe that information about this offset (i.e. size of
the stub) isn't already available somewhere in the exe file itself (either
in the general header or possibly in the COFF section headers), I just
don't know where to look. :-( Knowing where it is might allow doing this
in completely transparent manner - we could load information from the EXE
file under all Coff platforms and already receive the right value for all
of them. Obviously, one possible source of information might be DJGPP C
sources for the gdb, but I'm not quite ready for this adventure... On the
other hand, the previous version indeed simply added 2048 to all ofsets
under GO32v2 (the code was completely GO32v2 specific then though), so
actually the hack mentioned above at least wouldn't make it worse than it
was in 2.2.x and before.

Tomas