I was inspecting the preprocessed output generated by GCC, and I see a lot of these in the .i file that I generated using the -save-temps flag:
# 8 "/usr/include/i386-linux-gnu/gnu/stubs.h" 2 3 4
What do the numbers before and after the absolute path of stubs.h mean? It seems to be some kind of debugging information that is inserted by the preprocessor and allows the compiler to issue error messages referring to this information. These lines do not affect the program itself, but what specifically is each number for?
Based on the documentation the number before the filename is the line number. The numbers after the file name are a flag and mean the following:
1 indicates the start of a new file.
2 indicates returning to a file (after having included another file).
3 indicates that the following text comes from a system header file, so certain warnings should be suppressed.
4 indicates that the following text should be treated as being wrapped in an implicit extern "C" block.
Related
I am generating some .lib(eg- libcef_dll_wrapper.lib) files and later after some steps using this .lib file in myCustomApp. I am getting below error in Visual Studio debug build only.
LNK2038 mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in customfile.obj
There are many steps between creation of this .lib file and using it in my custom application. Is there any way so that i can check ITERATOR_DEBUG_LEVEL value just after creation of this .lib file? Please help.
I am afraid, how this information is stored in a .lib archive file is not well documented.
A compiler stores the value with the name "_ITERATOR_DEBUG_LEVEL" got by _STRINGIZE(_ITERATOR_DEBUG_LEVEL).
#define _STRINGIZEX(x) #x
#define _STRINGIZE(x) _STRINGIZEX(x)
You may parse a .lib archive and .obj files in an archive and look for "_ITERATOR_DEBUG_LEVEL" value.
The code bellow from yvals.h detects the value mismatch while linkage, see #pragma detect_mismatch
#pragma detect_mismatch("_ITERATOR_DEBUG_LEVEL", _STRINGIZE(_ITERATOR_DEBUG_LEVEL))
When you link the project, the linker throws a LNK2038 error if the project contains two objects that have the same name but each has a different value. Use this pragma to prevent inconsistent object files from linking.
Both name and value are string literals and obey the rules for string literals with respect to escape characters and concatenation. They are case-sensitive and cannot contain a comma, equal sign, quotation marks, or the null character.
While compiling a c file, gcc by default compiles it to a file called "a.out". My professor said that the output file contains the binaries, but I when I open it I usually encounter unreadable text (VS Code says something like "This file contains unsupported text encoding").
I assumed that by 'binaries', I would be able to see literal zeroes and ones in the file but that does not seem to be the case. So what exactly does it output file look like or what exactly does it contain and what is 'text encoding'? Why can I not read it? What special characters might it contain? I'm aware of the fact that gcc first pre-processes, which means it removes all comments, expands all macros and copies the contents of any header files that might be included. You get the header file by running gcc -E <file_name>.c, then the this processed file is complied into assembly. Up to this point, the output files are readable, i.e., I can open them with VS Code, but after this the assembled code and the object file thereafter are human-unreadable.
For reference, I have no prior experience with programming or any language for that matter and this is my first CS related course in my first sem of college, and I apologize if this is too trivial of a question to ask.
I actually had the same confusion early on. Not about that file type specifically, but about binary vs text files.
After all aren't all files, even text ones binary? In the sense that all information is 1s and 0s? Well, yes, all information can be stored/transmitted as 1s and 0s, but that's not what binary/text files refer to.
It refers to what that information, the content of the file, those 1s and 0s represent.
In a text file the bytes encode characters. In a binary file the bits encode some information that is not text. The format and semantics of that information is completely free, it can mean anything and use whatever encoding scheme. It's up to the application that writes/reads the file to properly understand the bit patterns.
Most text editors (like VS Code) when open a file they treat it as a text file. I.e. they try to interpret the bit patterns as a text encoding scheme (e.g. ASCII or UTF-8) But not all bit patterns are valid ASCII/UTF-8 so that's why you get "unsupported text encoding".
If you want to inspect the actual 1s and 0 for both text and binary files you need to use a utility that shows you that, e.g. hex viewers/editors.
My source code is referring to some Screen Names & DB tables. Sample declarations given below:
FSCRNNAME CF E WORKSTN
FDBNM1 IF E K DISK
I'm using the MicroFocus Rumba editor for compiling and using the built-in Compile within the Rumba Editor "Work with Members using PDM" (option 14 - for compile).
While compiling, I'm getting the following errors:
Error Messages:
1) "DATA DESCRIPTIONS FOR FILE SCRNAME NOT FOUND"
2) "DATA DESCRIPTIONS FOR FILE DBNM1 NOT FOUND"
3) "External description not found for file specified as externally described. File ignored.
Has anyone have a solution for this ?
Thanks!
The libraries containing the files SCRNAME and DBNM1 have to be in the library list for the compile.
Sorry, I don't know Rumba so I don't know how you would set your library list. But it sounds like you might be using an emulator, so maybe you could use the ADDLIBLE command before you use option 14 to compile.
It seems that the compiler cannot find the video file.
If you compile interactively, before running 14 on the PDM make sure that the library containing the compiled video is listed.
to search for the full video type in command line
WRKOBJ SCRNNAME
if you find it, it means that it is in the library list
otherwise
WRKOBJ * ALL / SCRNNAME
to find all the libraries that contain it
When you have found the library you can add it to the library list.
ADDLIBLE libraryName will add it in the first position
EDTLIBL send allows you to edit it in the position you prefer.
If you compile in Batch make sure that the library containing the video file is in the library list associated with the job queue of your JOB
with F18 from PDM you can set the job queue to be associated with the compiled
WRKJOBQ to modify job queues, including build parameters.
Does anybody know whether it's possible to get the error-row of a file being compiled when the error occurs in an include file?
For example, I'm compiling a file, say abc.p, that uses def.i all over the place. At some point, I make a change to abc.p that causes a compile error in one of the includes, so the message says that the error occurred at line 123 of def.i, but I want to know at which line in abc.p that is. In other words, the line number where the offending include file is used.
Even though "Compiler:Get-File-Name(n)" returns def.i and "Compiler:File-Name" returns abc.p, both "Compiler:Get-Row(n)" as well as "Compiler:Error-Row" returns the line number in def.i.
Any ideas?
My guess would be to save the compiler listing or debug file and look at that.
Beyond that, I don't think there's a way to do it now - you need to submit an enhancement request to get this functionality.
My way of tracking this kind of error is with
compile source.p preprocess source.pp.
open source.pp in the procedure editor and check syntax.
This gives you the error location in the expanded source.
Once you have found that locate code that is not part of the include and search for that code in the original source.
AFAIK, .dll is in PE format, what about .lib?
There is 2 kind of files with .lib extension :
the static library (for static linking)
The import library (for dynamic linking)
Both are an archive of COFF files. The format of this archive is an 'ar archive'.
The unix (cygwin/mingw) command ar can parse this file like the tar command does.
If you want to see the archived file in a .lib, you can do:
ar tv <name>.lib
Generally, if you see .obj file, it means that it is a static library.
If you see .dll then it is an import library.
I always though they were COFF format
See here for more info: http://support.microsoft.com/?id=121460 (archive)
Common Object File Format (COFF)
Article ID: Q121460
Creation Date: 05-OCT-1994
Revision Date: 12-OCT-1994
The information in this article applies to:
Microsoft Windows NT operating system version 3.1
Microsoft Windows NT Advanced Server version 3.1
Microsoft Windows NT Workstation version 3.5
Microsoft Windows NT Server version 3.5
SUMMARY
Windows NT uses a special format for the executable (image) files and object files. The format used in these files are referred to as Portable Executable (PE) or Common Object File Format (COFF) files. The name Portable Executable refers to the fact that executable files can run on more than one platform. This article describes in detail the internal features of PE/COFF file formats and its parameters.
MORE INFORMATION
The PE/COFF file headers consist of a MS-DOS stub, file signature, COFF Header, and Optional Header. An object file contains only the COFF Header, but an image file contains all the headers described above. The most important of these headers is the COFF header. The table below describes the information stored in the COFF header.
Offset Size Field Description
0 2 Machine Number identifying type of target machine.
2 2 Number of Sections Number of sections; indicates size of the
Section Table, which immediately follows
the headers.
4 4 Time/Date Stamp Time and date the file was created.
8 4 Pointer to Symbol Offset, within the COFF file, of the symbol
Table table.
12 4 Number of Symbols Number of entries in the symbol table.
This data can be used in locating the
string table, which immediately follows
the symbol table.
16 2 Optional Header Size of the optional header, which is
Size included for executable files but not
object files. An object file should have a
value of 0 here.
18 2 Characteristics Flags indicating attributes of the file.
Windows NT Software Development Kit (SDK) provides a utility called
DUMPBIN. DUMPBIN is a 32-bit tool that displays information about 32-bit
Common Object File Format (COFF) binary files. DUMPBIN runs only from a
command prompt. You can use DUMPBIN to examine the following kinds of COFF
files: object files, standard libraries of COFF objects, executable files,
and dynamic-link library (DLL) files.
To run DUMPBIN, use the following syntax:
DUMPBIN [options] [files]
The following are options parameters and definitions for DUMPBIN:
/ALL
/ARCHIVEMEMBERS
/DISASM
/EXPORTS
/HEADERS
/IMPORTS
/LINENUMBERS
/LINKERMEMBER[:{1|2}]
/OUT:filename
/PDATA
/RAWDATA[:{NONE|BYTES|SHORTS|LONGS}[,#]]
/RELOCATIONS
/SECTION:name
/SUMMARY
/SYMBOLS
Options Definition
/ALL Setting this option causes DUMPBIN to display all
available information except code disassembly.
/ARCHIVEMEMBERS Setting this option causes DUMPBIN to display minimal
information about member objects in a library.
/DISASM Setting this option causes DUMPBIN to show disassembly
of code sections, using symbols if present in the file.
/EXPORTS This option causes DUMPBIN to list all definitions
exported from an executable file or DLL.
/HEADERS Setting this option causes DUMPBIN to display the file
header and the header for each section. When used with a
library, displays the header for each member object.
/IMPORTS This option causes DUMPBIN to list all definitions
imported to an executable file or DLL.
/LINENUMBERS Setting this option causes DUMPBIN to show COFF line
numbers. Line numbers exist in an object file if it was
compiled with /Zi. An executable file or DLL contains
COFF line numbers if it was linked with /DEBUG and
/DEBUGTYPE:COFF option.
/LINKERMEMBER [[:{1|2}]]
Setting this option causes DUMPBIN to list public symbols
defined in a library. Specify the 1 argument to display
symbols in object order, along with their offsets. Specify
the 2 argument to display offsets and index numbers of
objects, then list the symbols in alphabetical order along
with the object index for each. To get both outputs,
specify /LINKERMEMBER without the number argument.
/OUT:<filename> This option specifies a filename for the output.
/RAWDATA [[:{BYTES|SHORTS|LONGS|NONE}[[,number]]]]
Setting this option causes DUMPBIN to display the raw
contents of each section in the file. The arguments
control the format of the display, as follows:
Argument - Result
BYTES - The default. Contents are displayed in hexadecimal bytes,
and also as ASCII if they have a printed representation.
SHORTS - Contents are displayed in hexadecimal words.
LONGS - Contents are displayed in hexadecimal longwords.
NONE - Raw data is suppressed. This is useful to control the
output of /ALL.
number - Displayed lines are set to a width that holds number
values per line.
/RELOCATIONS Setting this option causes DUMPBIN to display any
relocations in the object or image.
/SECTION: <section>
This option restricts the output to information on the
specified section.
/SUMMARY Setting this option causes DUMPBIN to display minimal
information about sections, including total size. This
option is the default if no other option is specified
in a DUMPBIN command.
/SYMBOLS Setting this option causes DUMPBIN to display the COFF symbol
table. Symbol tables exist in all object files. A COFF symbol
table appears in an image file only if it is linked with
/DEBUG /DEBUGTYPE:COFF
Some compilers (eg. Microsoft) use COFF format and some (eg. Borland/Codegear) use OMF format.
Here's description of microsoft's Lib file (same content, working link) format.
Examining a lib file in a hex editor (Visual Studio 2010), the data seems to be the same as an .a file on unix... an ar archive. It has two special files (with empty names) in the beginning that are some sort of symbol list.
EDIT: found a duplicate question Which format does static library (*.lib) files use? Where can I find "Official" specifications of *.LIB file structure/format? - it has a link that confirms this.
If you're interested in actually viewing the contents:
Wayne J. Radburn's PEView can decode it
and 7-zip can also give limited view of it