open-watcom / open-watcom-v2

Open Watcom V2.0 - Source code repository, Wiki, Latest Binary build, Archived builds including all installers for download.
Other
991 stars 163 forks source link

Create Listing files with wdis only 2 Byte addresses #1302

Closed headscott closed 4 months ago

headscott commented 5 months ago

Hey, I wanted to create a listing file for my whole project, which is bigger than 64k Bytes. So I would need 4 Byte addresses in the resulting result.lst file.

What I am doing now is:

wcc386 -zq -ob -oc -zls -s -d1 -d2 -fo=code.obj code.c

for all of my c files.

Then I link them with wlink and create the listing files for each c file seperately:

wdis code.obj -s=code.c > code.lst

now I got 2 questions/problems:

1) The addresses at the left of each assembly line only have 2 Bytes (for example: 0AE7 8B 00 mov eax,[eax]). Is it possible to make it 4 Bytes? Is it a restriction of the compiler or does wdis only use 2 Bytes, even though 4 Bytes would be possible by the compiler output? 2) Can I somehow merge all my .lst files into one, so that the addresses of external function calls and symbols are set correctly, just like the executable would jump to when the call appears? Or maybe directly create one for my whole project when linking?

I would need 4 Bytes, cause all my .lst files compined have more than 200k Bytes of instructions

jmalak commented 5 months ago

Below is usage text.

Open Watcom Multi-processor Disassembler
Version 2.0 beta Jun 10 2024 20:49:19 (64-bit)
Copyright (c) 2002-2024 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1995-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.

Usage:  wdis [options] obj_file [options]
Options:
          ( /option is also accepted )
-?          print this message
-a          generate assembleable output
-e          generate lists of externs
      Instruction format
-f{f,i,p,r,u}
  f         - FPU emulator fixups as comment [80(x)86 only]
  i         - use alternate indexing format [80(x)86 only]
  p         - do not use instruction name pseudonyms
  r         - do not use register name pseudonyms [RISC only]
  u         - instructions/registers in upper case
-i=<char>   initial character of internal labels
-l[=<file>] generate listing file
-m          leave C++ names mangled
-p          generate list of publics
-s[=<file>] include source lines

Address size is determined by object module address range that cannot be overflowed. By default it is 16-bit (near 100% of object files) and if need more then it is extended to 32-bit. Normaly -a option is used which generate assemblable source code. What you use is encoding output which is used rather for analysis of problems.

!!!! it is not reverse engineering tool !!!!

headscott commented 5 months ago

So if I have a single module which needs more than 16-bit, it will increase automatically to 32-bit?

And I don't need normal assembly code. I want to use the lst files for debugging reasons.

This is also why I want a listing file for the whole project, so if there is a call for an external function, I don't need to open another file, but can stay inside the same and directly see the address where it jumps.

jmalak commented 5 months ago

But it is work for Linker, you should generate Linker map file where symbols real address in executable is listed. You can use linker option opt map But normaly is to run executeble in debugger and you have no such problems.

headscott commented 5 months ago

Yeah I know, but the debugger I am using, would need some kind of .lst file. And I know about the map file. I hoped there is a combination for both. Maybe I would have to build that on my own based on all lst files for each module and the map file from the linker

jmalak commented 5 months ago

In map file you can sort it by modules or by address or both lists.