If I do something like this:
dumpbin myexe.exe
I got output similar to:
Dump of file myexe.exe
File Type: EXECUTABLE IMAGE
Summary
21000 .data
1000 .gfids
3C9000 .rdata
4F000 .reloc
B4000 .rsrc
325000 .text
1000 .tls
Second column (.data, .gfids, .rdata...) represents section name.
But what is first column? Section size?
This value is actually the aligned section size.
If you do dumpbin /headers myexe.exe, you will get a more verbose output. For example, dumpbin C:\Windows\explorer.exe on my system produces:
Dump of file c:\Windows\explorer.exe
File Type: EXECUTABLE IMAGE
Summary
4000 .data
1000 .didat
1000 .imrsiv
18000 .pdata
7B000 .rdata
6000 .reloc
1EA000 .rsrc
1C5000 .text
dumpbin /headers C:\Windows\explorer.exe, contains the output for the .text section as follows (... = lines omitted):
...
SECTION HEADER #1
.text name
1C4737 virtual size
1000 virtual address (0000000140001000 to 00000001401C5736)
1C4800 size of raw data
400 file pointer to raw data (00000400 to 001C4BFF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
60000020 flags
Code
Execute Read
...
It also gives 1000 section alignment in the OPTIONAL HEADER VALUES section.
As you can see, the size of the .text section is actually 1C4737, when aligned, it becomes 1C5000, as reported in the /summary (which is the default option for dumpbin).
Related
Here is how I define the rom module
module rom(
input wire [31:0] inst_addr_i,
output reg [31:0] inst_o
);
reg [31:0] rom_mem[0:100];
always#(*) begin
inst_o = rom_mem[inst_addr_i>>2];
end
endmodule
Here is the $readmem in tb.v
initial begin
$readmemh("inst.data",tb.rv_soc_ins.rom_ins.rom_mem);
end
And the inst.data file is like this, which has 354 rows.
00000d13
00000d93
00000093
00000113
00208f33
00000e93
00200193
This is what I get when executing the vpp script:
$ vvp a.out
WARNING: tb.v:23: $readmemh(inst.data): Too many words in the file for the requested range [0:100].
VCD info: dumpfile gtk.vcd opened for output.
Although in rom.v, I have set the rom large enough.
reg [31:0] rom_mem[0:100];
The above declaration means that you have a memory with 101 32-bit words.
[0:100] means there are 101 locations (addresses) in the memory.
[31:0] means the memory location (data) is 32 bits wide.
Your inst.data file has 354 rows (or lines) in the file. Each row you showed has one 32-bit data word. Assuming you have one word on each row for the remainder of the file, then you have 354 words in the file.
The warning message tells you that your rom is not large enough to fit all the data words in the file.
I added some comments to the data file to illustrate what Verilog does with the data:
00000d13 // row 1 data loaded into rom_mem[0]
00000d93 // row 2 data loaded into rom_mem[1]
00000093
00000113
...
11111111 // row 100 data loaded into rom_mem[99]
22222222 // row 101 data loaded into rom_mem[100]
33333333 // row 102 data is discarded
...
ffffffff // row 354 data is discarded
As you can see, only the first 101 data words are loaded into the memory. The remaining data words are not used.
If you really want your memory to be 32x101 and you want to get rid of the warning, then you can delete the lines of the file starting at line 102, or you could specify start and end addresses:
$readmemh("inst.data", tb.rv_soc_ins.rom_ins.rom_mem, 0, 101);
If you really want your memory to be 32x354, then you need to change the rom module:
reg [31:0] rom_mem[0:353];
Refer to IEEE Std 1800-2017, section 21.4 Loading memory array data from a file.
The warning is saying that your file (with 354 rows) is longer than your array (with 101 elements).
The message about VCD is unconnected: it is simply the next message telling you that the file "gtk.vcd" has been opened.
I want to put a breakpoint in a Linux share library in specific offset ( in libTest.so in function 0x1234 ) while I debugging with GEF GDB. But I want to put it with gdb script.
If I run vmmap libTest.so I got
[ Legend: Code | Heap | Stack ]
Start End Offset Perm Path
0x00000012a1XXX 0x00000012a3XXX 0x00000000000000 r-x /lib/libTest.so
0x00000012a3XXX 0x00000012a5XXX 0x000000000XXXX --- /lib/libTest.so
0x00000012aXXXX 0x00000012aXXXX 0x000000000XXXX r-- /lib/libTest.so
0x00000012aXXXX 0x00000012aXXXX 0x000000000XXXX rw- /lib/libTest.so
So the first line is where the code located. So I want to put a breakpoint in 0x00000012a1XXX+0x1234
For now I put that code in GDB script
python
str = gdb.execute('vmmap libTest.so', False, True)
addr_base= (str.split('\n')[2].split(' ')[0])
gdb.execute('b '+addr_base+0x1234)
end
But that is bad code.
Is there any simple way?
I am using readelf --hex-dump=<section name> <elf> to get hex dump of a specific section. However, the result is shown as big endian DWORD. Is there a native way to make the output little endian?
Hex dump of section 'PrgCode':
0x1ffe0000 b0b54ef2 0010cef2 00000168 490507d5 ..N........hI...
0x1ffe0010 4ff48061 c0f88010 bff34f8f bff36f8f O..a......O...o.
0x1ffe0020 0021c5f2 2d410a68 4cf22050 cdf62810 .!..-A.hL. P..(.
0x1ffe0030 92040246 5ebf4cf2 20524a60 4df62812 ...F^.L. RJ`M.(.
0x1ffe0040 4a604ff6 ff728a60 0b6843f0 200323f0 J`O..r.`.hC. .#.
How do I fix USER FATAL MESSAGE 740? This error is generated by Nastran when I try to run a BDF/DAT file of mine.
*** USER FATAL MESSAGE 740 (RDASGN)
UNIT NUMBER 5 HAS ALREADY BEEN ASSIGNED TO THE LOGICAL NAME INPUT
USER ACTION: CHANGE THE UNIT NUMBER ON THE ASSIGN STATEMENT AND IF THE UNIT IS USED FOR
PARAM,POST,<0 THEN SPECIFY PARAM,OUNIT2 WITH THE NEW UNIT NUMBER.
AVOID USING THE FOLLOWING UNIT NUMBERS THAT ARE ASSIGNED TO SPECIAL FILES IN MSC.NASTRAN:
1 THRU 12, 14 THRU 22, 40, 50, 51, 91, 92. SEE THE MSC.NASTRAN INSTALLATIONS/OPERATIONS
GUIDE SECTION ON MAKING FILE ASSIGNMENTS OR MSC.NASTRAN QUICK REFERENCE GUIDE ON
ASSIGN PHYSICAL FILE FOR REFERENCE.
Below is the head of my BDF file.
assign userfile='SUB1_PLATE.csv', status=UNKNOWN, form=formatted, unit=52
SOL 200
CEND
ECHO = NONE
DESOBJ(MIN) = 35
set 30=1008,1007,1015,1016
DESMOD=SUB1_PLATE
SUBCASE 1
$! Subcase name : DefaultLoadCase
$LBCSET SUBCASE1 DefaultLbcSet
ANALYSIS = STATICS
SPC = 1
LOAD = 6
DESSUB = 99
DISPLACEMENT(SORT1,PLOT,REAL)=ALL
STRESS(SORT1,PLOT,VONMISES,CORNER)=ALL
BEGIN BULK
param,xyunit,52
[...]
ENDDATA
Below is the solution
Correct
assign userfile='SUB1_PLAT.csv', status=UNKNOWN, form=formatted, unit=52
I shortened the name of CSV file to SUB1_PLAT.csv. This reduced the length of the line to 72 characters.
Incorrect
assign userfile='SUB1_PLATE.csv', status=UNKNOWN, form=formatted, unit=52
The file management section is limited to 72 characters, spaces included. The incorrect line stretches 73 characters. The nastran reader ignores the 73rd character and on. Instead of reading "unit=52" the reader reads "unit=5" which triggers the error.
|<--------------------- 72 Characters -------------------------------->||<- Characters are ignored truncated ->
assign userfile='SUB1_PLATE.csv', status=UNKNOWN, form=formatted, unit=52
References
MSC Nastran Reference Guide
The records of the first four sections are input in free-field format
and only columns 1 through 72 are used for data. Any information in
columns 73 through 80 may appear in the printed echo, but will not be
used by the program. If the last character in a record is a comma,
then the record is continued to the next record.
I am reading large files in Fortran that contain mixed string/numeric data such as:
114 MIDSIDE 0 0 O0002 436 437 584 438
115 SURFACE M00002 0 0 359 561 560 356
412236 SOLID M00002 O00001 0 86157 82419 82418 79009
Currently, each line is read as a string and then post-processed to identify the proper terms. I was wondering if there is any way to read each line as an integer followed by four strings separated by space, and then some more integers; i.e. similar to '(I10,4(A6,X),4I10)' format, but without any information on the size of each string.
Does not work (charr is empty, iarr(2:5)=0):
INTEGER IARR(5)
CHARACTER*30 CHARR(4)
C open the file with ID=1
READ(1,*)IARR(1),(CHARR(I),I=1,4),(IARR(I),I=2,5)
Works (only for the last line in the data example):
INTEGER IARR(5)
CHARACTER*30 CHARR(4)
C open the file with ID=1
READ(1,'(I10,4(A7,X),4I10)')IARR(1),(CHARR(I),I=1,4),(IARR(I),I=2,5)
The issue is I don't know a-priori what would be the size of each string.
I actually found out the f77rtl flag was used to compile the project, and when I removed the flag, the issue was resolved. So the list-directed input format works just fine.