wlink fails to set a default entry point and the created ELF program crashes

For the mips target on linux, assembling the bld/as/mps/test/hello.asm works, but when linking with owcc, wlink fails to set a valid entry point (wling uses NULL as default) and the resulting elf program segfaults.

Tested with qemu-mipsel and on a real mips machine When i change the entry point in the elf header, the program works. When i use the gnu linker ld to link the object file created by wasmps, the program works.

Using wlinkto link the object file created by the GNU Assembler is not possible (wlink does not recognice that file as a valid elf object file).

My modified hello.asm can be assembled with OpenWatcom toolchain and with the GNU [cross] toolchain.

(The included 64bit programs will not output the expected text, because i did not update the syscall numbers yet) (The 64 bit files are included as additional testfiles for wdump with elf64 support)

Updated hello.asm, object files, executabe files and a test script are attached: mps_test.tar.gz

-- Regards ... Detlef

it is unsupported platform that if something is wrong then you must fix it yourself I don't understand how you decide what is proper start symbol for program and why wlink is wrong ???? As usually some statement without understanding what is correct and what not and how it works and all should works as with GNU. What about error message generated by wlink ???? GNU is not any standard that what works with GNU logically doesn't work with others !

By example default toolchains program entry points Microsoft is mainCRTStartup GNU is _start OW is _cstart_ .... What you report as problem is your ilussion that GNU is standard and because you don't understand what you are doing. If you want to use non-default entry point(OW) then you can use OW assembler directive

.new_section .drectve, "iRr0"
                .asciiz "-entry:_start"

or use wlink directive to specify program entry point. Anyway 64-bit ELF modules is not tested that nothing is guarantied that you can implement missing features and fix problems.

it is unsupported platform

I know, that mips-linux is an unsupported platform, and i expect, that fixing this bug is a low priority.

if something is wrong then you must fix it yourself

I do not know the wlink commandline options and the wlink codebase good enough yet to locate and fix the issue. "git grep" directed me to something near FmtData, StartInfo and LinkState, but there are still too many results for me to find out, why the entry point in the resulting program has no usable address.

I don't understand how you decide what is proper start symbol for program and why wlink is wrong ????

wlink sets 0x0000000 as start adress, that's wrong. ELF files for i686-linux have a default load adress of 0x08048000 and the default start is at the first code byte. But i have no idea, when wlink decides to use a resonable entry point, when creating a i686-linux program.

OpenWatcom knows that load adress at `bld/wl/c/objcalc.c:728 and has even a working load adress for mips nearby (0x00400000). But that is not used

As usually some statement without understanding what is correct and what not

An ELF start adress of 0x00000000 is not correct here and creates a segfault when used with "qemu-mipsel" and on real hardware

What about error message generated by wlink ????

owcc -march=mps  hello_wasmps.o -o hello_wasmps_owcc
    wlink @__owcc00.lnk 
Open Watcom Linker Version 2.0 beta Jun 10 2024 18:37:19 (64-bit)
Copyright (c) 2002-2024 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See https://github.com/open-watcom/open-watcom-v2#readme for details.
loading object files
Warning! W1023: no starting address found, using 00000000
creating a Linux MIPS executable

GNU is not any standard what works with GNU logically doesn't work with others !

Sorry, that is not always correct. Examples, what the linux kernel defines as part of the userspace ABI, and what you might not like, because it has "GNU" in the name. PT_GNU_STACK and PT_GNU_PROPERTY https://www.kernel.org/doc/html/latest/userspace-api/ELF.html

By example default toolchains program entry points Microsoft is mainCRTStartup GNU is _start OW is _cstart_

_start is used the given source file, which is already in the OW tree, and i had the asumption, that there was a time, when that code worked.

When i change the source to use _cstart_ (and similar underscore variants), it doesn't work either.

If you want to use non-default entry point(OW) then you can use OW assembler directive
.new_section .drectve, "iRr0"
                .asciiz "-entry:_start"

Thanks, that's a useful info for later

or use wlink directive to specify program entry point.

I found the wlink option "START="symbol name, but what can i do to let wlink use the defaults for the specific arch which is already in the wlink code, but unfortunately not used.

Anyway 64-bit ELF modules is not tested nothing is guarantied you can implement missing features and fix problems.

I know all these things, and i'm working in this area. Step by step.

Since you always like to blame everything related to the gnu toolchain, i tried something similar with jwasm (a fork of wasm, but far more advanced).

For this test, I build JWasm locally with gcc from my distribution an used it with wlink.

There is no "Hello World" example for x86-linux in bld/wasmtest, so i had to use the "Helle World" example from jwasm. It's in JWasm/Samples/Linux1.asm: https://github.com/Baron-von-Riedesel/JWasm/blob/master/Samples/Linux1.asm

Comparsion results (source renamed to "hello_wasm.asm")

wasm  -Fo=hello_wasm_omf.o hello_wasm.asm
wlink format ELF runtime linux file hello_wasm_omf.o  name  hello_wasm_omf

hello_wasm_omf entrypoint: 0x8048100

jwasm -omf -Fo=hello_jwasm_omf.o hello_wasm.asm
wlink format ELF runtime linux file hello_jwasm_omf.o  name  hello_jwasm_omf

hello_jwasm_omf entrypoint: 0x8048100

And here is the bug in wlink again, but now for x86 on linux:

jwasm -elf -Fo=hello_jwasm_elf.o hello_wasm.asm
wlink format ELF runtime linux file hello_jwasm_elf.o  name  hello_jwasm_elf
Warning! W1023: no starting address found, using 00000000

hello_jwasm_elf entrypoint: 0x0

When you try it yourself, you will recognice, that wasm and jwasm handle mov edx, sizeof string differently (I used mov edx, 15 instead)

cross-building with 'jwlink' is not possible, since building 'jwlink' on linux is not implemented.

it is unsupported platform

I know, that mips-linux is an unsupported platform, and i expect, that fixing this bug is a low priority.

nobody will fix it if nobody is working on it.

if something is wrong then you must fix it yourself

I do not know the wlink commandline options and the wlink codebase good enough yet to locate and fix the issue. "git grep" directed me to something near FmtData, StartInfo and LinkState, but there are still too many results for me to find out, why the entry point in the resulting program has no usable address.

Don't start write that OW doesn't work properly. Mostly it is due to you do absolutely incorrect things and don't read documentation or source code.

I don't understand how you decide what is proper start symbol for program and why wlink is wrong ????

wlink sets 0x0000000 as start adress, that's wrong. ELF files for i686-linux have a default load adress of 0x08048000 and the default start is at the first code byte. But i have no idea, when wlink decides to use a resonable entry point, when creating a i686-linux program.

You should learn ELF format and how executable is linked. It is not magic, simply you must specify program entry and pass it to linker. Each toolchain has "default" entry point to not need to specify entry point each time, it is for lazy programmers.

OpenWatcom knows that load adress at `bld/wl/c/objcalc.c:728 and has even a working load adress for mips nearby (0x00400000). But that is not used

what I wrote above explain it.

As usually some statement without understanding what is correct and what not

An ELF start adress of 0x00000000 is not correct here and creates a segfault when used with "qemu-mipsel" and on real hardware

what I wrote above explain it.

What about error message generated by wlink ????

owcc -march=mps  hello_wasmps.o -o hello_wasmps_owcc
  wlink @__owcc00.lnk 
Open Watcom Linker Version 2.0 beta Jun 10 2024 18:37:19 (64-bit)
Copyright (c) 2002-2024 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See https://github.com/open-watcom/open-watcom-v2#readme for details.
loading object files
Warning! W1023: no starting address found, using 00000000
creating a Linux MIPS executable

It is transparent message, if you ignore it then nothing works.

GNU is not any standard what works with GNU logically doesn't work with others !

Sorry, that is not always correct. Examples, what the linux kernel defines as part of the userspace ABI, and what you might not like, because it has "GNU" in the name. PT_GNU_STACK and PT_GNU_PROPERTY https://www.kernel.org/doc/html/latest/userspace-api/ELF.html

What it has with executable linking ?????

By example default toolchains program entry points Microsoft is mainCRTStartup GNU is _start OW is _cstart_

"_start" is used the given source file, which is already in the OW tree, and i had the asumption, that there was a time, when that code worked.

When i change the source to use "cstart" (and similar underscore variants), it doesn't work either.

If you ignore what linker report and don't fix it then nothing works. what I wrote on the top explain it.

If you want to use non-default entry point(OW) then you can use OW assembler directive
.new_section .drectve, "iRr0"
                .asciiz "-entry:_start"
Thanks, that's a useful info for later

or use wlink directive to specify program entry point.

I found the wlink option "START="symbol name, but what can i do to let wlink use the defaults for the specific arch which is already in the wlink code, but unfortunately not used.

again you want change OW to be working by your opinion. If it doesn't work then you did something wrong and you must correct it. I don't uderstand you what problem is add single option to wlink? Sorry, again you expected that wlink do something strange, but it is different problem you are doing nonsens wlink only do what you instruct for.

Anyway 64-bit ELF modules is not tested nothing is guarantied you can implement missing features and fix problems.

I know all these things, and i'm working in this area. Step by step.

You mix lot of "your" problems to single issue which has nothing to do with title. Why you don't ask how to do something instead of logging OW is buggy? What sense? If something is buggy then log it as single issue and don't complicate thing by lot of unrelated information.

I have conclusion to this issue it is user mistake because user don't know how to enter program entry point to linker. Potentially may be some problem with ELF format but it has nothing to do with program entry point specification.

below is sample code and detailed wlink map file and wdump of ELF header for sample code which was created for demonstration how it works by following commands. Of cause the code is non-working only sample. No problem with linking and non-default Program entry point.

wasmps test.asm
wlink sys linuxmips opt map, verbose f test.obj

You can use source without special section

.new_section .drectve, "iRr0"
                .asciiz "-entry:_start"

Then you need to use modified wlink command wlink sys linuxmips opt map, verbose, start=_start f test.obj

Sample source (non-working, only for demonstration)

.text
    ret           $zero,($ra),0x00000001 
    ret           $zero,($ra),0x00000001 
.globl _start
_start:
    ret           $zero,($ra),0x00000001 

.new_section .drectve, "iRr0"
                .asciiz "-entry:_start"

Open Watcom Linker Version 2.0 beta Jul 26 2024 15:38:06 (32-bit)
Copyright (c) 2002-2024 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Created on:       24/08/06 07:23:28
Executable Image: test.elf
creating a Linux MIPS executable

                        +------------+
                        |   Groups   |
                        +------------+

Group                           Address              Size
=====                           =======              ====

                        +--------------+
                        |   Segments   |
                        +--------------+

Segment                Class          Group          Address         Size
=======                =====          =====          =======         ====

.text                  CODE           AUTO           00400100        0000000c

                        +----------------+
                        |   Memory Map   |
                        +----------------+

* = unreferenced symbol
+ = symbol only referenced locally

Address        Symbol
=======        ======

Module: test.obj(test.obj)
00400108+      _start

                        +---------------------+
                        |   Module Segments   |
                        +---------------------+

! = 32-bit segment
c = initialized communal data

Module          Segment               Class           Address         Size
======          =======               =====           =======         ====

test.obj        .text                 CODE           00400100  !      0000000c

                        +-----------------------+
                        |   Linker Statistics   |
                        +-----------------------+

Stack size:  1000 (4096.)
Memory size:  000c (12.)
Entry point address: 00400108
Link time: 00:00.00

Open Watcom Executable Image Dump Utility
Version 2.0 beta Aug  4 2024 18:21:51 (64-bit)
Copyright (c) 2002-2024 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See https://github.com/open-watcom/open-watcom-v2#readme for details.

                                  ELF Header
==============================================================================
class (1==32-bit objects, 2==64-bit objs)   =       01H
data  (1==little-endian, 2==big-endian)     =       01H
version                                     =       01H
OS/ABI type (0==unspecified)                =       03H
ABI version (0==unspecified)                =       00H
file type:                                  Executable file
file type (i.e. object, executable file)    =     0002H
required architecture                       =     0008H
version of the file                         = 00000001H
program entry point                         = 00400108H
program header offset                       = 00000034H
section header offset                       = 000010F8H
processor specific flags                    = 00000000H
ELF header size                             =     0034H
program header entry size                   =     0020H
number of program header entries            =     0001H
section header entry size                   =     0028H
number of section header entries            =     0006H
section name string table index             =     0001H

This bug report is related to the "default entry point".

It is still a single issue and still related to the title (but i must admit, that adding "ELF" to the title would make it more clear where the issue is, when reading only the title, instead of finding it out from readig the text. But i didn't know, that the bug is related to ELF handling, when i created the bug).

The bug was discovered, while working with an example for mips (experimental) and validated with an example for x86-linux (supported):

Link an ELF object file fails: default start address broken (tested for x86-linux and mips-linux)
Link an OMF object file works: default start address set (tested for x86-linux)

Thanks for your example. It demonstrates, that wlink works for ELF files, when a start-label was explicit set by giving an additional argument. But that example has nothing to do with the "default entry point".

I expect, that this bug will be discovered again in the future, when someone tries to enhance wlink to be able to link 64bit ELF object files to create 64bit ELF programs.

-- Regards ... Detlef

64bit ELF is not supported, I don't know where you get the info that it is supported and how do you generate 64bit code using OW? But it is standard that you take completely nonsense actions and give incomplete information and make an "excellent" conclusion. But read what you wrote, your title is completely off. No one knows what you actually reported as a problem. It's something different every time. Stop with such "weird" messages and start being serious. You always start by saying it's a bug. It's actually user error. You always report something that cannot work as it is bug. Your bug terminology is fantastic. Unfortunately, we cannot communicate on this basis, you are completely out and unless you change your style, I will ban you from Github. I tried to help you but you're just draining my resources that I could be using for something more useful for OW users than arguing with you about nonsense. Take this as a final warning.

open-watcom / open-watcom-v2

wlink fails to set a default entry point and the created ELF program crashes #1317