Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2015-06

Internal linker bug?

3 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

patspiper

Hi,

Linking a pascal project (with {$L mylib.obj}) with a specific .obj (COFF32) file using the internal linker (Windows) yields an executable that produces an exception when run. On the other hand, the external linker produces a sane executable.

The executable is supposed to contain calls from a unit to public functions in the .obj file, but these calls are to incorrect locations while the surrounding code is correct, hence the exception. eg:
External linker (correct): call function1
Internal linker (wrong) : call <fpc_widestr_to_ansistr+40>

A dump of the .obj file shows that all public functions have an offset (value) in the symbol table, but no relocation entry, whereas Static/Nonpublic and external symbols have a relocation entry even if the symbol table entry offset (value) is 0.

Is this a bug in the internal linker especially that the external linker does exhibit this behaviour?

Note: I am not too involved in .obj formats, so pls bear with me if the above is inaccurate.

Stephano

Reply by email

Mark Morgan Lloyd
to patspiper
patspiper wrote 24 lines
Hi, Linking a pascal project (with {$L mylib.obj}) with a specific .obj (COFF32) file using the internal linker (Windows) yields an executable that produces an exception when run. On the other hand, the external linker produces a sane executable. The executable is supposed to contain calls from a unit to public functions in the .obj file, but these calls are to incorrect locations while the surrounding code is correct, hence the exception. eg: External linker (correct): call function1 Internal linker (wrong) : call <fpc_widestr_to_ansistr+40> A dump of the .obj file shows that all public functions have an offset (value) in the symbol table, but no relocation entry, whereas Static/Nonpublic and external symbols have a relocation entry even if the symbol table entry offset (value) is 0. Is this a bug in the internal linker especially that the external linker does exhibit this behaviour? Note: I am not too involved in .obj formats, so pls bear with me if the above is inaccurate.

For the benefit of anybody who's not followed the thread, summary at http://lists.lazarus.freepascal.org/pipermail/lazarus/2015-June/092881.html including a link to the conversion tool (originally suggested by José Mejuto).

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

patspiper
to Mark Morgan Lloyd
Mark Morgan Lloyd wrote 30 lines
patspiper wrote: > Hi, > > Linking a pascal project (with {$L mylib.obj}) with a specific .obj > (COFF32) file using the internal linker (Windows) yields an > executable that produces an exception when run. On the other hand, > the external linker produces a sane executable. > > The executable is supposed to contain calls from a unit to public > functions in the .obj file, but these calls are to incorrect > locations while the surrounding code is correct, hence the exception. > eg: > External linker (correct): call function1 > Internal linker (wrong) : call <fpc_widestr_to_ansistr+40> > > A dump of the .obj file shows that all public functions have an > offset (value) in the symbol table, but no relocation entry, whereas > Static/Nonpublic and external symbols have a relocation entry even if > the symbol table entry offset (value) is 0. > > Is this a bug in the internal linker especially that the external > linker does exhibit this behaviour? > > Note: I am not too involved in .obj formats, so pls bear with me if > the above is inaccurate. For the benefit of anybody who's not followed the thread, summary at http://lists.lazarus.freepascal.org/pipermail/lazarus/2015-June/092881.html including a link to the conversion tool (originally suggested by José Mejuto).

The details above are not included in the lazarus mega-thread that you pointed out, and the latter adds almost nothing to the above info. So better not daunt fpc devs with such a thread.

Stephano

Reply by email