I have today the following flags used for size
arm-none-eabi-size --format=SysV -x
But this shows both the section size and its address in hex. using -d gives everything in decimal. Is it possible to combine the two to have size in decimal and address in hex?
with -x:
arm-none-eabi-size --format=SysV -x build/frog.elf
build/frog.elf :
section size addr
.isr_vector 0x298 0x8000000
...
with -d:
arm-none-eabi-size --format=SysV -d build/frog.elf
build/frog.elf :
section size addr
.isr_vector 664 134217728
...
I would like:
arm-none-eabi-size --format=SysV -??? build/frog.elf
build/frog.elf :
section size addr
.isr_vector 664 0x8000000
...
Related
I am trying to flash my yocto-generated image into a SAM9X60EK board but it's insanely slow, I think it's because of the write buffer size which is only 8KB (and the image is around 150MB) as shown below,
$ sam-ba -p serial -b sam9x60-ek -a nandflash -c write:microchip-headless-image-sam9x60ek.ubi:0x800000
Output:
Opening serial port 'ttyACM0' Connection opened.
Detected memory size is 536870912 bytes.
Page size is 4096 bytes.
Buffer is 8192 bytes (2 pages) at address 0x0030aca0.
NAND header value is 0xc1e04e07.
Supported erase block size: 256KB
or
Wrote 8192 bytes at address 0x00800000 (0.01%)
Wrote 8192 bytes at address 0x00802000 (0.01%)
…
…
Wrote 8192 bytes at address 0x0015c000 (99.83%)
Wrote 8192 bytes at address 0x0015e000 (100%)
Is there any possibility to make this process any faster?
You can try running this command before burning：
sam-ba -p serial -b sam9x60-ek -a lowlevel
I'm trying to understand where DW_FORM_strp attribute values are actually stored in an ELF file (can be found here: https://filebin.net/77bb8359o0ibqu67).
I've found sections .debug_info, .debug_abbrev and .debug_str. I've then parsed the compilation unit header in .debug_info, and found the abbreviation table entry for the compile unit and iterated over its abbreviations. The first abbreviation is DW_AT_producer with form DW_FORM_strp. What I'm wondering is how to find where this offset is located?
From the DWARF4 spec I read: Each debugging information entry begins with a code that represents an entry in a separate abbreviations table. This code is followed directly by a series of attribute values. My understanding of this is that if I go back to the compilation unit header, skip over its content, I should end up at the compilation unit. It starts with a ULEB128 (which I parse), after which the attribute values should come. However, in my ELF file those bytes are all 0. I've run readelf -w on the file, and I see the following:
Contents of the .debug_info section:
Compilation Unit # offset 0x0:
Length: 0xf6 (32-bit)
Version: 4
Abbrev Offset: 0x0
Pointer Size: 8
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<c> DW_AT_producer : (indirect string, offset: 0x62): GNU C11 7.5.0 -mtune=generic -march=x86-64 -g -O0 -fstack-protector-strong
<10> DW_AT_language : 12 (ANSI C99)
<11> DW_AT_name : (indirect string, offset: 0xd9): elf.c
<15> DW_AT_comp_dir : (indirect string, offset: 0xad): /home//struct_analyzer
<19> DW_AT_low_pc : 0x0
<21> DW_AT_high_pc : 0x39
<29> DW_AT_stmt_list : 0x0
This tells me that the offset into the string table is 0x62, and the name is at an offset 0xd9. However, after parsing the ULEB128 which is the first part of any DIE, the next 4 bytes (the first attribute's value) are 0x00 00 00 00. This I don't understand?
Edit to Employed Russian:
Yes, I understand that the offset 0x62 points into the .debug_str section. However, what I'm wondering is where I find this 0x62 value?
Each DIE starts with a ULEB128 value (the abbreviation table entry code), and is followed by the attributes. The first attribute in the corresponding abbreviation table entry is a DW_AT_producer of form DW_FORM_strp. This means that the next 4 bytes in the DIE are supposed to be the offset into .debug_str. However, the next 4 bytes are 0x00 00 00 00, and not 0x62 00 00 00 which is the value I'm looking. 0x62 is residing at offset 0x5c8 into the ELF file, whereas the DIE's attributes start at offset 0x85 as far as I can tell (see attached image for a hexdump (little endian) - highlighted byte is the ULEB128, and the following bytes are what I expect to be the offset into .debug_str).
Edit 2
I've been able to determine that the actual attribute values of form DW_FORM_strp are located in the .rela.debug_info section in the ELF file, so I'll have to read more about that.
The specific ELF file posted for this question also has a rela.debug_info section, which contains relocation entries for the .debug_info section. From the ELF spec:
.relaNAME
This section holds relocation information as described below.
If the file has a loadable segment that includes relocation,
the section's attributes will include the SHF_ALLOC bit. Oth‐
erwise, the bit will be off. By convention, "NAME" is sup‐
plied by the section to which the relocations apply. Thus a
relocation section for .text normally would have the name
.rela.text. This section is of type SHT_RELA.
Each relocation entry in this section (of type Elf64_Rela in this particular case) should be iterated over, and the value of each entry should be addended with the corresponding value in the .debug_info section.
This tells me that the offset into the string table is 0x62, and the name is at an offset 0xd9.
Correct. These offsets are into the .debug_str section, which starts at offset 0x289 in the file.
readelf -WS elf.o | grep debug_str
[12] .debug_str PROGBITS 0000000000000000 000289 0000e4 01 MS 0 0 1
dd if=elf.o bs=1 skip=$((0x289+0x62)) count=75 2>/dev/null
GNU C11 7.5.0 -mtune=generic -march=x86-64 -g -O0 -fstack-protector-strong
dd if=elf.o bs=1 skip=$((0x289+0xd9)) count=5 2>/dev/null
elf.c
P.S.
I've found sections .dwarf_info, .dward_abbrev and .dwarf_str.
None of above sections exit in your file. It helps to be precise when asking questions.
first post for help....
I am trying to get signal quality in % from the iwconfig command...
I began with this command but it returns the text 'signal value'
iwconfig wlan0 | grep Quality | awk -F '=|/|=[ ]' '{print $2,$3}'
70 70 Signal level
I'd like just want to have '100%' as a result
wlan0 IEEE 802.11 ESSID:"SKYNET"
Mode:Managed Frequency:2.412 GHz Access Point: AC:84:C9:CD:79:E0
Bit Rate=72.2 Mb/s Tx-Power=31 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=68/70 Signal level=-42 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:51 Invalid misc:0 Missed beacon:0
Following is doing (68/70)*100. using split() 68 is stored in a[2] whereas 70 is stored in a[3]
iwconfig wlan0|awk '/Link Quality/{split($2,a,"=|/");print (a[2]/a[3])*100"%"}'
97.1429%
for integer result:
iwconfig wlan0|awk '/Link Quality/{split($2,a,"=|/");print int((a[2]/a[3])*100)"%"}'
97%
or just use printf:
iwconfig wlan0|awk '/Link Quality/{split($2,a,"=|/");printf "%d%s\n", (a[2]/a[3])*100, "%"}'
97%
PS: Tested with the output supplied by OP in question.
I started to use contiki operating system with atmel atmega128rfa1.
I can compile my example, but the hex file is bad. The error is:
ERROR: address 0x820003 out of range at line 1740 of ipso.hex (i am not using IPSO, just i kept this name).
When I compile in linux system the code is program size is 27804 byte and the data is 4809byte.
When I compile in windows the program is 28292 and the data is 4791.
I use only one process and one etimer, I would like to turn on and off 1 led.
the makefile consinst of:
`
TARGET=avr-atmega128rfa1
CONTIKI = ../..
include $(CONTIKI)/Makefile.include
all:
make -f Makefile.ipso TARGET=avr-atmega128rfa1 ipso.elf
avr-objcopy -O ihex -R .eeprom ipso.elf ipso.hex
avr-size -C --mcu=atmega128rfa1 ipso.elf `
i can't program the controller. What is the problem?
thank you.
Special sections in the .elf file start above 0x810000 and must be removed when generating a hex file for programming a particular memory, e.g.
$ avr-objdump -h webserver6.avr-atmega128rfa1
webserver6.avr-atmega128rfa1: file format elf32-avr
Sections:
Idx Name Size VMA LMA File off Algn
0 .data 00001bda 00800200 0000e938 0000ea2c 2**0
CONTENTS, ALLOC, LOAD, DATA
1 .text 0000e938 00000000 00000000 000000f4 2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .bss 000031a6 00801dda 00801dda 00010606 2**0
ALLOC
3 .eeprom 00000029 00810000 00810000 00010606 2**0
CONTENTS, ALLOC, LOAD, DATA
4 .fuse 00000003 00820000 00820000 0001062f 2**0
CONTENTS, ALLOC, LOAD, DATA
5 .signature 00000003 00840000 00840000 00010632 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
So,
avr-objcopy -O ihex -R .eeprom -R .fuse -R signature ipso.elf ipso.hex
alternately, only copy the desired sections:
avr-objcopy -O ihex -j .text -j .data ipso.elf ipso.hex
avr-objcopy --change-section-lma .eeprom=0
this works for me
$ objdump -f ./a.out
./a.out: file format elf32-i386
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x080484e0
$ objdump -f function.o
function.o: file format elf32-i386
architecture: i386, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
What is the meaning of flags (flags 0x00000011: OR flags 0x00000112:) ? Nothin in the ELF header file has this flag. e_flag contain 0.
Someone have an idea about his meaning ?
Thanks
They are BFD-specific bitmasks. In the binutils source tree, see bfd/bfd-in2.h:
/* BFD contains relocation entries. */
#define HAS_RELOC 0x01
/* BFD is directly executable. */
#define EXEC_P 0x02
...
/* BFD has symbols. */
#define HAS_SYMS 0x10
...
/* BFD is dynamically paged (this is like an a.out ZMAGIC file) (the
linker sets this by default, but clears it for -r or -n or -N). */
#define D_PAGED 0x100
These flag values won't appear in your object file; they are simply an in-memory representation that libbfd uses.
They are LibBFD flags.
You're trying to recode objdump ? ... =)