Re: [fpc-devel] Internal linker bug?
On 25/06/15 15:21, Mark Morgan Lloyd wrote: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Internal linker bug?
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Internal linker bug?
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). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel