How can I get the Watcom compiler (the forked version 2.0 beta which runs on 64-bit hosts) to output 8086 assembly source code in an ASM file? Running wcc -0 main.c from the command prompt produces just the OBJ file.
As a side note, my main task it to convert C source code to assembly code that I can run with EMU8086 (instead of writing the actual assembly code). I am hoping the ASM file generated by Watcom would run without modification (copy-paste) in EMU8086.
I don't see a way to get the Watcom compiler to generate an ASM file directly, but you should be able to use the Watcom disassembler (wdis) to generate an assembly listing from the object file produced by the compiler. In this case you would run something like wdis -l main to read main.obj and produce a file named main.lst that contains an assembly language listing.
If you recompile main.c with a -d1 or -d2 option to place extra debugging data into the main.obj file then you can use the disassembler's -s option to have the assembly language listing interpersed with comments showing the original C source from main.c.
To get the disassembler to omit descriptive comments and just give a plain disassembly that should be acceptable as a source file for the Watcom assembler, give the -a option to the disassembler. This option will also causes the disassembler's output to be written into main.asm rather than main.lst. Sorry, I have no idea whether this output will be directly consumable by EMU8086.
This is all discussed in the Open Watcom C/C++ User Guide and C/C++ Tools User Guide linked from http://www.openwatcom.com/doc.php
I use embedded system. After the C source code building I get many files. The file name is the same, but the extension is different:
.s37
.elf
.hex
.sig
What is the differences between them? Mainly what is the differences between .s37 and .elf?
Those are just different executable formats.
.s37 is one variant of SREC format, it's ascii/line fixed text including hex (binary)
This format is well known by flash/upload software in most embedded targets.
.elf is an executable & linkable file, product of a linker like gcc or other commercial compilers (Windriver, CodeWarrior...).
.elf format is hardly uploadable on embedded targets without conversion to .SREC with objcopy first.
One of the main differences in contents is that .elf format can contain debugging symbols, whereas .srec/.s37 cannot.
My guess is that your toolchain does it all: link: .elf, then objcopy to convert .elf to .s3 for target upload (losing symbol information if any, which requires you to keep the .elf file handy when debugging your application on the target, the SREC file contains only code & data, no debug).
S3 format can't contain symbols. They're discarded, even using a simple objcopy command. That format is only useful to contain code/data to upload on a target.
I have a source code with multiple files.How to extract the file & function details from elf using c program
How to extract the file & function details from elf using c program.
This requires non-trivial amount of programming. There are libraries which can help: libelf and libdwarf. Or you can read sources for readelf.
I am beginning with mruby, and I need a little in generating readable .c code using mrbc. I was following this article :
Here it is mentioned :
$ mruby/bin/mrbc -Cinit_tester test_program.rb
will produce test_program.c with some content.
but on my machine when I run this command it says :
mrbc: output file should be specified to compile multiple files
Then I tried
$ mruby/bin/mrbc -Binit_tester test_program.rb
which works , generates c files but its contents are only bytecode:
#include <stdint.h>
const uint8_t init_tester[] = {0x45,0x54,0x49,0x52,0x30,0x30,0x30,0x33,0x73,0x0d,0x00,0x00,0x00,0x65,0x4d,0x41,0x54,0x5a,0x30,0x30,0x30,0x30,0x49,0x52,0x45,0x50,0x00,0x00,0x00,0x47,0x30,0x30,0x30,0x30,0x00,0x00,0x00,0x3f,0x00,0x01,0x00,0x04,0x00,0x00,0x00,0x00,0x00,0x04,0x06,0x00,0x80,0x00,0x3d,0x00,0x00,0x01,0xa0,0x00,0x80,0x00,0x4a,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x0b,0x68,0x65,0x6c,0x6c,0x6f,0x20,0x77,0x6f,0x72,0x6c,0x64,0x00,0x00,0x00,0x01,0x00,0x04,0x70,0x75,0x74,0x73,0x00,0x45,0x4e,0x44,0x00,0x00,0x00,0x00,0x08, };
Which is basically byte code of the mruby code that we have put in c code.
If you look at the blog m under section Readable C Code (.c), this should have actually generated c code.
why is the mrbc not generating readable c code ?
why is the mrbc not generating readable c code?
Well, mrbc is a compiler to generate the binary format of ruby code with RiteVM understands so there is no way of generating a readable C code.
Instead with -v option you can see AST and VM codes of your code
(I prefer to pass -c option too since mrbc will generate *.mrb files without it) .
This may be compiler specific, in which case I am using the IAR EWARM 5.50 compiler (firmware development for the STM32 chip).
Our project consists of a bunch of C-code libraries that we compile first, and then the main application which compiles its C-code and then links in those libraries (pretty standard stuff).
However, if I use a hex editor and open up any of the library object files produced or the final application binary, I find a whole bunch of plain text references inside the output binary to the file paths of the C files that were compiled. (eg. I see "C:\Development\trunk\Common\Encryption\SHA_1.c")
Two issues with this:
we don't really want the file paths being easily readable as that indicates our design some what
the size of the binary grows if you have your C-files located in a long subdirectory (the binary contains the full path, not just the name)...this is especially important when we're dealing with firmware that has a limited amount of code space (256KB).
Any thoughts on this? I've tried all the switches in the compiler I can think of to "remove debug information", etc., but those paths are still in there.
"The command-line option --no_path_in_file_macros has been added. It removes the path leaving only the filename for the symbols FILE and BASE_FILE."
It is defined in the release notes if IAR.
http://supp.iar.com/FilesPublic/UPDINFO/005832/arm/doc/infocenter/iccarm_history.ENU.html
Or you can look for FILE and BASE_FILE macros and remove it you do not want to use the flag.