how to set flag EXEC_P in elf file - gcc

I make an elf file from an intel-hex file using riscv64-unknown-elf-objcopy.
exact command:
riscv64-unknown-elf-objcopy -O elf32-littleriscv --set-start 0x10000000 --rename-section .sec1=.text image32.ihex image32.elf
the result looks like this:
$ riscv64-unknown-elf-readelf image32.elf -h
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: RISC-V
Version: 0x1
Entry point address: 0x10000000
Start of program headers: 0 (bytes into file)
Start of section headers: 136148 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 8
Section header string table index: 7
My purpose is to execute it using 'Spike'.
Spike does not accept my elf file:
spike --isa=RV32IM --priv=MU -m0x10000000:0x00200000 --real-time-clint image32.elf
spike: ../fesvr/elfloader.cc:36: std::map<std::__cxx11::basic_string<char>, long unsigned int> load_elf(const char*, memif_t*, reg_t*): Assertion `IS_ELF_EXEC(*eh64)' failed.
It does accept elf files with the following header:
$ riscv64-unknown-elf-readelf ok.elf -h
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: RISC-V
Version: 0x1
Entry point address: 0x10000000
Start of program headers: 52 (bytes into file)
Start of section headers: 54672 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 40 (bytes)
Number of section headers: 23
Section header string table index: 22
I guess I need to change the "Type" field from "REL" to "EXEC", but I do not see any option for that in objcopy.

This post suggests that the following sequence might do what you want:
riscv64-unknown-elf-objcopy -I ihex -O binary image32.ihex image32.bin
riscv64-unknown-elf-objcopy -I binary -O riscv64-unknown-elf image32.bin image32.elf
But I am just guessing :-(

Related

How to generate a position independent executable with nasm and ld?

I have a simple nasm code:
test.nasm
section .text
global _start
_start:
jmp _start
ret
I build it as below:
nasm -f elf64 test.nasm -o test.o
ld test.o -o test -pie
Then I tried to run it:
./test
It gives me this:
bash: ./test: No such file or directory
So I checked the file header:
readelf -h test
It shows this:
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file) <====== NOT an executable
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x1f0
Start of program headers: 64 (bytes into file)
Start of section headers: 4616 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 6
Size of section headers: 64 (bytes)
Number of section headers: 12
Section header string table index: 11
But I can easily create a position independent executable with GCC for below program:
test2.c
#include <stdio.h>
void main(void)
{
printf("hello, pie!\n");
}
I build it with:
gcc test2.c -o test2 -pie
It runs like this:
hello, pie!
So how can I create a position independent executable with nasm and ld rather than a shared object?
ADD 1
I checked the test2 ELF header. It is also a shared object. So it may not be the problem. (Thanks to #Nate Eldredge)
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file) <===== ALSO a shared object
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x530
Start of program headers: 64 (bytes into file)
Start of section headers: 6440 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 9
Size of section headers: 64 (bytes)
Number of section headers: 29
Section header string table index: 28
So how can I use ld to get a position-independent executable from the object file generated with nasm?

Why readelf add "#GLIBC_2.2.5 (2)" after FUNC symbols' names in .dynsym symbol table

I'm learning ELF file and using a C HelloWorld program built by GCC on x86_64 CentOS 7 as an example to investigate the executable.
I can understand how the name of a symbol is found for every symbol in the executable except two in dynamic symbol table (.dynsym).
Take symbol "main" in symbol table (.symtab) for example:
$ readelf -s HelloWorld
...
Symbol table '.symtab' contains 84 entries:
Num: Value Size Type Bind Vis Ndx Name
...
80: 0000000000400586 21 FUNC GLOBAL DEFAULT 13 main
...
Its original value is:
Name of this symbol
^^ ^^ ^^ ^^
00001e20 00 00 00 00 00 00 00 00 fb 03 00 00 12 00 0d 00 |................|
00001e30 86 05 40 00 00 00 00 00 15 00 00 00 00 00 00 00 |..#.............|
The value is 0x0000 03fb (small edian). It is actually an offset in section .strtab with the following content:
$ readelf -p .strtab HelloWorld
String dump of section '.strtab':
...
[ 3fb] main
...
So it is easy to understand that the name of this symbol is "main". And every symbol which is in either .symtab or .dynsym and has a name follows this rule, except two in .dynsym. The two exceptions are:
$ readelf -s HelloWorld
Symbol table '.dynsym' contains 6 entries:
Num: Value Size Type Bind Vis Ndx Name
...
2: 0000000000000000 0 FUNC GLOBAL DEFAULT UND puts#GLIBC_2.2.5 (2)
3: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main#GLIBC_2.2.5 (2)
...
Take symbol #2 for example, its original value is:
Name of the symbol
^^ ^^ ^^ ^^
000002e0 00 00 00 00 00 00 00 00 0b 00 00 00 12 00 00 00 |................|
000002f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Offset of the symbol name 0x0000 000b. By looking at .dynstr:
$ readelf -p .dynstr HelloWorld
String dump of section '.dynstr':
[ 1] libc.so.6
[ b] puts
[ 10] __libc_start_main
[ 22] GLIBC_2.2.5
[ 2e] _ITM_deregisterTMCloneTable
[ 4a] __gmon_start__
[ 59] _ITM_registerTMCloneTable
I can see the the String at offset 0xb is "puts". But why a character "#" is appended by readelf? And why the String "GLIBC_2.2.5" (at offset 0x22) is appended, too?
But why a character "#" is appended by readelf? And why the String "GLIBC_2.2.5" (at offset 0x22) is appended, too?
These are GNU-versioned symbols. readelf appends that info to make it clear, otherwise you'll see e.g. this:
1232: 00000000000792d0 471 FUNC GLOBAL DEFAULT 13 fmemopen
1233: 0000000000078ed0 527 FUNC GLOBAL DEFAULT 13 fmemopen
and will be confused by how there could be two separate fmemopens at different addresses.
Current output:
1232: 00000000000792d0 471 FUNC GLOBAL DEFAULT 13 fmemopen#GLIBC_2.2.5
1233: 0000000000078ed0 527 FUNC GLOBAL DEFAULT 13 fmemopen##GLIBC_2.22
shows that these symbols have different version info attached to them, and that the GLIBC_2.22 version is the default one.
You can read more about GNU versioned symbols here.

Disable writing disk signature to MBR in Windows (Address 01B8, 01BC)

Windows is writting a disk signature (serial number) to the Master boot record, if the two addresses 01B8 (4 bytes) and 01BC (2 bytes) are zeros.
You can export the first 512 bytes from the drive with dd. Then open diskmgmt.msc. After that, the disk should be initialized and the disk signature was written. Export again the first 512 bytes to another file and do a hexdiff of the two files. You'll see the different bytes in the above mentioned addresses.
Can I disable this behaviour in Windows, e.g. in the registry?
I'm on Windows 7.
diffs:
raw - signature zero
0000 01B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 ........ .......
windows altered - signature filled in 01B8 (4 bytes)
0000 01B0: 00 00 00 00 00 00 00 00 72 44 E7 89 00 00 00 20 ........ rDþë...
Setting the disk to the offline state, does the trick.
diskpart
list disk
select disk N
offline disk
exit

How to extract a section from a file with awk or grep

I'm working on a script that needs to extract a few information from smbiosDump from ESXi. The smbiosDump looks something like this:
Dumping live SMBIOS data!
BIOS Info: #0
Size: 0x00018
Vendor: "FUJITSU // American Megatrends Inc."
Version: "V5.0.0.11 R1.2.0 for D3373-B1x"
Date: "03/16/2017"
Start Address: 0xf0000
ROM Size: 16384 kB
Features: 0x0d03000000013c099880
PCI supported
BIOS flashable
BIOS shadowing allowed
CD boot supported
Selectable boot supported
EDD spec supported
Print Screen supported
8042 Keyboard Services supported
Serial Services supported
Printer Services supported
ACPI supported
USB Legacy supported
BIOS Boot Spec supported
Enable targeted content distribution
UEFI supported
System BIOS release: 1.2
Port Connector: #4
Type: 0x08 (Serial Port 16550 Compatible)
Internal Designator: "Serial"
External Designator: "Serial 1"
External Connector: 0x08 (DB-9 pin male)
Port Connector: #5
Type: 0x1c (Video Port)
Internal Designator: "VGA"
External Designator: "Rear: Video"
External Connector: 0x07 (DB-15 pin female)
Port Connector: #6
Type: 0x1f (Network Port)
Internal Designator: "LAN i210-AT"
External Designator: "LAN 1"
External Connector: 0x0b (RJ-45)
Port Connector: #7
Type: 0x1f (Network Port)
Internal Designator: "LAN i210-AT"
External Designator: "LAN 2"
External Connector: 0x0b (RJ-45)
Port Connector: #8
Type: 0x1f (Network Port)
Internal Designator: "iRMC-S4"
External Designator: "LAN M"
External Connector: 0x0b (RJ-45)
Port Connector: #9
Type: 0x10 (USB)
Internal Designator: "USB 2.0 REAR"
External Designator: "Rear: USB 1"
External Connector: 0x12 (Access Bus [USB])
Port Connector: #10
Type: 0x10 (USB)
Internal Designator: "USB 2.0 REAR"
External Designator: "Rear: USB 2"
External Connector: 0x12 (Access Bus [USB])
Port Connector: #11
Type: 0x10 (USB)
Internal Designator: "USB 2.0 REAR"
External Designator: "Rear: USB 3"
External Connector: 0x12 (Access Bus [USB])
Port Connector: #12
Type: 0x20 (SATA)
Internal Designator: "SATA 1-4"
Internal Connector: 0xff (Other)
Port Connector: #13
Type: 0x20 (SATA)
Internal Designator: "SATA 5 DOM"
Internal Connector: 0x22 (Other)
Port Connector: #14
Type: 0x20 (SATA)
Internal Designator: "SATA 6 DOM"
Internal Connector: 0x22 (Other)
Port Connector: #15
Type: 0x10 (USB)
Internal Designator: "UFM"
Internal Connector: 0xff (Other)
Port Connector: #16
Type: 0x10 (USB)
Internal Designator: "DAT"
Internal Connector: 0x12 (Access Bus [USB])
Port Connector: #17
Type: 0xff (Other)
Internal Designator: "TPM HDR"
Internal Connector: 0xff (Other)
System Slot: #18
Designation: "SLOT 1"
Type: 0xa5 (PCI Express)
Bus Width: 0x08 (x1)
Status: 0x03 (Available)
Length: 0x03 (Short)
Slot ID: 1
Characteristics: 0x0104 (3.3 V, PME#)
System Slot: #19
Designation: "SLOT2"
Type: 0xa5 (PCI Express)
Bus Width: 0x0a (x4)
Status: 0x04 (In Use)
Length: 0x03 (Short)
Slot ID: 2
Characteristics: 0x0104 (3.3 V, PME#)
System Slot: #20
Designation: "SLOT3"
Type: 0xa5 (PCI Express)
Bus Width: 0x0b (x8)
Status: 0x04 (In Use)
Length: 0x03 (Short)
Slot ID: 3
Characteristics: 0x0104 (3.3 V, PME#)
System Slot: #21
Designation: "SLOT4"
Type: 0xa5 (PCI Express)
Bus Width: 0x0b (x8)
Status: 0x04 (In Use)
Length: 0x03 (Short)
Slot ID: 4
Characteristics: 0x010c (3.3 V, Shared, PME#)
On Board Devices: #22
Video: "VGA iRMC4"
Ethernet: "LAN i210-AT"
Ethernet: "LAN i210-AT"
OEM Strings: #23
FUJITSU
FUJITSU
FUJITSU TECHNOLOGY SOLUTIONS
System Config Options (Jumpers & Switches) #24:
PWD-CLR: Password Skip active
RCVR: Recovery BIOS active
Hardware Security: #25
Power-on Password: 0x00 (Disabled)
Keyboard Password: 0x02 (Not Implemented)
Admin Password: 0x00 (Disabled)
Front Panel Reset: 0x02 (Not Implemented)
Type 32 Record: #26
Data 00: 20 14 1a 00 00 00 00 00 00 00 00 00 00 00 00 00
Data 10: 00 00 00 00
Type 41 Record: #27
Data 00: 29 0b 1b 00 01 83 01 00 00 03 00
String 1: "VGA iRMC4"
Type 41 Record: #28
Data 00: 29 0b 1c 00 01 85 01 00 00 04 00
String 1: "LAN i210-AT"
Type 41 Record: #29
Data 00: 29 0b 1d 00 01 85 02 00 00 05 00
String 1: "LAN i210-AT"
Type 38 Record: #30
Data 00: 26 12 1e 00 01 20 20 ff a3 0c 00 00 00 00 00 00
Data 10: 00 00
Cache Info: #31
Designation: "L1 Cache"
Level: L1
State: Enabled
Mode: 0x00 (Write Through)
Location: 0x00 (Internal, Not Socketed)
ECC: 0x02 (Unknown)
Type: 0x04 (Data)
Associativity: 0x07 (8-way Set-Associative)
Max. Size: 128 kB
Current Size: 128 kB
Supported SRAM Types: 0x0002 (Unknown)
Current SRAM Type: 0x0002 (Unknown)
Cache Info: #32
Designation: "L1 Cache"
Level: L1
State: Enabled
Mode: 0x00 (Write Through)
Location: 0x00 (Internal, Not Socketed)
ECC: 0x02 (Unknown)
Type: 0x03 (Instruction)
Associativity: 0x07 (8-way Set-Associative)
Max. Size: 128 kB
Current Size: 128 kB
Supported SRAM Types: 0x0002 (Unknown)
Current SRAM Type: 0x0002 (Unknown)
Cache Info: #33
Designation: "L2 Cache"
Level: L2
State: Enabled
Mode: 0x00 (Write Through)
Location: 0x00 (Internal, Not Socketed)
ECC: 0x05 (Single-bit)
Type: 0x05 (Unified)
Associativity: 0x05 (4-way Set-Associative)
Max. Size: 1024 kB
Current Size: 1024 kB
Supported SRAM Types: 0x0002 (Unknown)
Current SRAM Type: 0x0002 (Unknown)
Cache Info: #34
Designation: "L3 Cache"
Level: L3
State: Enabled
Mode: 0x01 (Write Back)
Location: 0x00 (Internal, Not Socketed)
ECC: 0x05 (Single-bit)
Type: 0x05 (Unified)
Associativity: 0x09 (12-way Set-Associative)
Max. Size: 6144 kB
Current Size: 6144 kB
Supported SRAM Types: 0x0002 (Unknown)
Current SRAM Type: 0x0002 (Unknown)
Processor Info: #35
Payload length: 0x30
Socket: "CPU1"
Socket Type: 0x01 (Other)
Socket Status: Populated
Type: 0x03 (CPU)
Family: 0xb3 (Xeon)
Manufacturer: "Intel(R) Corporation"
Version: "Intel(R) Xeon(R) CPU E3-1280 v6 # 3.90GHz"
Processor ID: 0xbfebfbff000906e9
Status: 0x01 (Enabled)
Voltage: 1.1 V
External Clock: 100 MHz
Max. Speed: 4200 MHz
Current Speed: 3900 MHz
L1 Cache: #32
L2 Cache: #33
L3 Cache: #34
Core Count: #4
Core Enabled Count: #4
Thread Count: #8
Physical Memory Array: #36
Use: 0x03 (System memory)
Location: 0x03 (Motherboard)
Slots: 4
Max. Size: 64 GB
ECC: 0x05 (Single-bit)
Memory Device: #37
Location: "DIMM CHA3"
Bank: "BANK 0"
Manufacturer: "Samsung"
Serial: "002FEFAAF"
Asset Tag: "0123456789"
Part Number: "M391A1K43BB1-CRC"
Memory Array: #36
Form Factor: 0x09 (DIMM)
Type: 0x1a (DDR4)
Type Detail: 0x0080 (Synchronous)
Data Width: 64 bits (+8 ECC bits)
Size: 8 GB
Speed: 2400 MHz
Memory Device: #38
Location: "DIMM CHA1"
Bank: "BANK 1"
Manufacturer: "Samsung"
Serial: "002FEFABA"
Asset Tag: "0123456789"
Part Number: "M391A1K43BB1-CRC"
Memory Array: #36
Form Factor: 0x09 (DIMM)
Type: 0x1a (DDR4)
Type Detail: 0x0080 (Synchronous)
Data Width: 64 bits (+8 ECC bits)
Size: 8 GB
Speed: 2400 MHz
Memory Device: #39
Location: "DIMM CHB4"
Bank: "BANK 2"
Manufacturer: "Samsung"
Serial: "002FEFB14"
Asset Tag: "0123456789"
Part Number: "M391A1K43BB1-CRC"
Memory Array: #36
Form Factor: 0x09 (DIMM)
Type: 0x1a (DDR4)
Type Detail: 0x0080 (Synchronous)
Data Width: 64 bits (+8 ECC bits)
Size: 8 GB
Speed: 2400 MHz
Memory Device: #40
Location: "DIMM CHB2"
Bank: "BANK 3"
Manufacturer: "Samsung"
Serial: "002FEFAB7"
Asset Tag: "0123456789"
Part Number: "M391A1K43BB1-CRC"
Memory Array: #36
Form Factor: 0x09 (DIMM)
Type: 0x1a (DDR4)
Type Detail: 0x0080 (Synchronous)
Data Width: 64 bits (+8 ECC bits)
Size: 8 GB
Speed: 2400 MHz
Memory Array Mapping: #41
Memory Array: #36
Partition Width: 4
Start Address: 0x0000000000000000
End Address: 0x0000000800000000
Type 176 Record: #42
Data 00: b0 24 2a 00 00 00 73 33 00 11 33 00 02 31 ff ff
Data 10: 72 fd ad 6a 08 39 a4 89 04 46 a1 4d f9 4a 28 3f
Data 20: 01 00 01 00
Type 177 Record: #43
Data 00: b1 2a 2b 00 12 00 00 00 12 00 00 00 12 05 00 00
Data 10: 0b 01 02 00 00 00 00 00 00 00 00 12 00 00 00 00
Data 20: 00 00 00 00 00 00 00 00 00 00
Type 188 Record: #44
Data 00: bc 08 2c 00 30 39 31 24
Type 136 Record: #45
Data 00: 88 06 2d 00 5a 5a
System Info: #46
Manufacturer: "FUJITSU"
Product: "PRIMERGY TX1320 M3"
Serial: "YMBK000042"
UUID: 09000800070006000500040003000200
Wake-up: 0x06 (Power Switch)
Board Info: #47
Manufacturer: "FUJITSU"
Product: "D3373-B1"
Version: "S26361-D3373-B12 WGS03 GS51"
Serial: "50896663"
Type: 0x0a (Motherboard)
Features: 0x09
Hosting Board
Replaceable
Chassis: #3
Chassis Info: #48
Manufacturer: "FUJITSU"
Version: "TX1320M3F5"
Serial: "YMBK000042"
Asset Tag: "System Asset Tag"
Type: 0x11 (Main Server Chassis)
Bootup State: 0x03 (Safe)
Power Supply State: 0x03 (Safe)
Thermal State: 0x03 (Safe)
Security Status: 0x03 (None)
Memory Device Mapping: #49
Memory Device: #37
Array Mapping: #41
Interleave Pos: 1
Interleaved Depth: 2
Start Address: 0x0000000000000000
End Address: 0x0000000200000000
Memory Device Mapping: #50
Memory Device: #38
Array Mapping: #41
Interleave Pos: 1
Interleaved Depth: 2
Start Address: 0x0000000400000000
End Address: 0x0000000600000000
Memory Device Mapping: #51
Memory Device: #39
Array Mapping: #41
Interleave Pos: 2
Interleaved Depth: 2
Start Address: 0x0000000200000000
End Address: 0x0000000400000000
Memory Device Mapping: #52
Memory Device: #40
Array Mapping: #41
Interleave Pos: 2
Interleaved Depth: 2
Start Address: 0x0000000600000000
End Address: 0x0000000800000000
Type 221 Record: #53
Data 00: dd 1a 35 00 03 01 00 04 01 00 01 00 02 00 00 00
Data 10: 00 48 00 03 00 00 05 00 00 00
String 1: "Reference Code - CPU"
String 2: "uCode Version"
String 3: "TXT ACM version"
Type 221 Record: #54
Data 00: dd 44 36 00 09 01 00 04 01 00 01 00 02 03 ff ff
Data 10: ff ff ff 04 00 ff ff ff 31 00 05 00 ff ff ff 31
Data 20: 00 06 00 ff ff ff ff ff 07 00 3e 00 00 00 00 08
Data 30: 00 34 00 00 00 00 09 00 3e 00 00 00 00 0a 00 34
Data 40: 00 00 00 00
String 1: "Reference Code - SKL PCH"
String 2: "PCH-CRID Status"
String 3: "Disabled"
String 4: "PCH-CRID Original Value"
String 5: "PCH-CRID New Value"
String 6: "OPROM - RST - RAID"
String 7: "SKL PCH H Bx Hsio Version"
String 8: "SKL PCH H Dx Hsio Version"
String 9: "SKL PCH LP Bx Hsio Version"
String 10: "SKL PCH LP Cx Hsio Version"
Type 221 Record: #55
Data 00: dd 36 37 00 07 01 00 04 01 00 01 00 02 00 04 01
Data 10: 00 01 00 03 00 04 01 00 00 00 04 05 ff ff ff ff
Data 20: ff 06 00 ff ff ff 05 00 07 00 ff ff ff 05 00 08
Data 30: 00 ff ff ff ff ff
String 1: "Reference Code - SA - System Agent"
String 2: "Reference Code - MRC"
String 3: "SA - PCIe Version"
String 4: "SA-CRID Status"
String 5: "Disabled"
String 6: "SA-CRID Original Value"
String 7: "SA-CRID New Value"
String 8: "OPROM - VBIOS"
Type 221 Record: #56
Data 00: dd 60 38 00 0d 01 00 00 00 00 00 00 02 00 ff ff
Data 10: ff ff ff 03 04 ff ff ff ff ff 05 06 ff ff ff ff
Data 20: ff 07 08 ff ff ff ff ff 09 00 00 00 00 00 00 0a
Data 30: 00 ff ff ff ff 00 0b 00 ff ff 00 00 00 0c 00 ff
Data 40: ff ff ff ff 0d 00 ff ff ff ff ff 0e 00 ff ff ff
Data 50: ff ff 0f 00 ff ff ff ff ff 10 11 01 02 02 03 00
String 1: "Lan Phy Version"
String 2: "Sensor Firmware Version"
String 3: "Debug Mode Status"
String 4: "Disabled"
String 5: "Performance Mode Status"
String 6: "Disabled"
String 7: "Debug Use USB(Disabled:Serial)"
String 8: "Disabled"
String 9: "ICC Overclocking Version"
String 10: "UNDI Version"
String 11: "EC FW Version"
String 12: "GOP Version"
String 13: "BIOS Guard Version"
String 14: "Base EC FW Version"
String 15: "EC-EC Protocol Version"
String 16: "Royal Park Version"
String 17: "BP1.2.2.0_RP03"
Group Associations: #57
Group Name: "Firmware Version Info"
Items: #53, #54, #55, #56
Language Info: #58
Languages: en|US|iso8859-1
Current: en|US|iso8859-1
On different systems the dump is different, either longer or shorter.
I need to extract a few information from this dump file and from other similar dump files, the L1 (or L2, or L3) Cache Max. Size information. and make it print out something like this:
Level: L1
Max Size: 128 kb
I would also like to note that the Cache Info numbering (#32, #31, etc) is different for every system. What is #31 here could be #41 on another system, or #29. So trying to use the numbering as a filter will not work unfortunately..
(The same goes for L2 or L3, but on a different script.)
(Since on my original question, i had to make a new post, here is the other page: How can I extract a section of a file based on matching only one line?)
Could anyone please help me out with this?
You can pipe your dump to egrep :
…|egrep 'Level|Max. Size'
This will select only lines containing either Level or Max. Size.
If you don't want to bother removing Max. Size lines not associated to a Level by hand, you can pipe further into awk :
…|egrep 'Level|Max. Size'|awk '$1!=prevline{print $0}{prevline=$1;}'
This will check that the first word ($1) is not the same as in prevline, then print the whole line, and store the first word in prevline.

gcc can not find .o in archive

mipsisa64-octeon-elf-gcc obj/zxmd_main.o obj/zxmd_mproc.o obj/zxmd_init.o obj/zxmd_pcie.o obj/libcvm-common.a obj/libcvm-pci-drv.a obj/libcvmhfao.a obj/libocteon-hfa.a /home/jianxi/Juson/JusonFlow/sdk/OCTEON-SDK/components/hfa/lib-octeon/pp/octeon/se/libpp.a obj/libcvmx.a obj/libzxexe.a obj/libfdt.a -mfix-cn63xxp1 -march=octeon2 -o cn63hw1.bin
gcc complain:
obj/libzxexe.a(zxmx_tim.o): In function `zxmx_init_tim':
/home/jianxi/Juson/JusonFlow/libexec/zxmx_tim.c:47: undefined reference to `cvmx_tim_setup'
But cvmx_tim_setup can be found in libcvmx.a:
[jianxi#jianxi obj]$ readelf -h libcvmx.a | grep "cvmx-tim.o" -A21
File: libcvmx.a(cvmx-tim.o)
ELF Header:
Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 13424 (bytes into file)
Flags: 0x808d4001, noreorder, octeon2, eabi64, mips64r2
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 33
Section header string table index: 30
[jianxi#jianxi obj]$ readelf -s cvmx-tim.o
27: 00000000 92 FUNC GLOBAL DEFAULT 1 cvmx_tim_start
28: 00000000 40 OBJECT GLOBAL DEFAULT 16 cvmx_tim
29: 00000060 56 FUNC GLOBAL DEFAULT 1 cvmx_tim_stop
30: 00000098 276 FUNC GLOBAL DEFAULT 1 cvmx_tim_shutdown
31: 000001b0 752 FUNC GLOBAL DEFAULT 1 cvmx_tim_setup
32: 00000000 0 NOTYPE GLOBAL DEFAULT UND cvmx_clock_get_rate
33: 00000000 0 NOTYPE GLOBAL DEFAULT UND cvmx_bootmem_alloc
34: 00000000 0 NOTYPE GLOBAL DEFAULT UND memset
35: 00000000 0 NOTYPE GLOBAL DEFAULT UND puts
36: 00000000 0 NOTYPE GLOBAL DEFAULT UND printf
When i added cvmx-tim.o in the command , gcc will be executed successfully:
mipsisa64-octeon-elf-gcc obj/cvmx-tim.o obj/zxmd_main.o obj/zxmd_mproc.o obj/zxmd_init.o obj/zxmd_pcie.o obj/libcvm-common.a obj/libcvm-pci-drv.a obj/libcvmhfao.a obj/libocteon-hfa.a /home/jianxi/Juson/JusonFlow/sdk/OCTEON-SDK/components/hfa/lib-octeon/pp/octeon/se/libpp.a obj/libcvmx.a obj/libzxexe.a obj/libfdt.a -mfix-cn63xxp1 -march=octeon2 -o cn63hw1.bin
And if put obj/libcvmx.a in front of obj/zxmd_main.o , gcc will report more errors.
Why gcc can not find cvmx-tim.o in the libcvmx.a?
The order of *.o will cause problems?
It's the order of the libraries:
obj/libcvmx.a obj/libzxexe.a
by the time the linker searches obj/libzxexe.a it has already processed obj/libcvmx.a - it won't search it again for anything that was not already been pulled in when obj/libcvmx.a was processed the first time around.
Change the order of those libraries to:
obj/libzxexe.a obj/libcvmx.a
Besides changing the order of the libraries, you can also force the cvmx_tim_setup to be a marked as 'undefined' symbol in command line. If the symbol is known to be required, then the linker will be on the lookout for it and remember the first library defining it.
add this flag to gcc command: -Wl,--undefined=cvmx_tim_setup
Additionally you can also experiment with --start-group and --end-group in gcc. --start-group (list of binaries to link) --end-group. This will allow a full circular closure for searches. But will cost some link performance.
Ref:
http://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking
Paxym

Resources