I'm analyzing a dump which shows something strange: there seem to be a contradiciton between the command !heap -x -v hexadecimal_address and !heap -flt s size_of_block
I'm inquiring about dangling pointers.
In this dump, this dangling pointer happened to be: 0x0bdd00c0
To retrieve info about the heap memory block I use !heap -x -v 0bdd00c0 which returns
Entry User Heap Segment Size PrevSize Unused Flags
-----------------------------------------------------------------------------
0bdd00b8 0bdd00c0 003b0000 0bc00000 98 20 8 busy
Which shows namely that in this case:
the memory block is in busy mode (most of the time in my other dumps the memory is free here)
the memory block is 0x98 bytes big
the memory block is managed inside the heap 003b0000.
What puzzles me:
When I launch !heap -flt s 98 (just wanting to observe other objects that would have the same size)
I get this result which doesn't display the pointer 0bdd00c0 of my investigation
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
_HEAP # 3b0000
14b24fa8 0014 0014 [01] 14b24fb0 00098 - (busy)
0bc645a8 0014 0014 [01] 0bc645b0 00098 - (busy)
0bc66398 0014 0014 [01] 0bc663a0 00098 - (busy)
0bcbedf8 0014 0014 [01] 0bcbee00 00098 - (busy)
0bce2cc8 0014 0014 [01] 0bce2cd0 00098 - (busy)
0bceff88 0014 0014 [00] 0bceff90 00098 - (free)
0bdf2f78 0014 0014 [01] 0bdf2f80 00098 - (busy)
0be28c50 0014 0014 [01] 0be28c58 00098 - (busy)
0be57470 0014 0014 [00] 0be57478 00098 - (free)
0beed050 0014 0014 [01] 0beed058 00098 - (busy)
0bf1aaf0 0014 0014 [00] 0bf1aaf8 00098 - (free)
0bf214c0 0014 0014 [00] 0bf214c8 00098 - (free)
0bf99bf0 0014 0014 [00] 0bf99bf8 00098 - (free)
(I gave you only the heap 3b0000 related excerpt)
So I came to the conclusion that there seem to be a contradiction.
Am I doing/assuming something wrong ? What could I do to understand what's wrong ?
You have overlooked the 8 unused bytes, try
!heap -flt s 90
From My Test prog:
0:000> !heap -x -v 0x003dc710
Entry User Heap Segment Size PrevSize Unused Flags
-----------------------------------------------------------------------------
003dc708 003dc710 003d0000 003d0000 1310 40 d busy
0:000> ? 1310-d
Evaluate expression: 4867 = 00001303
0:000> !heap -flt s 1303
_HEAP # 3d0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
003dc708 0262 0000 [00] 003dc710 01303 - (busy)
More detail of the allocation here:
0:000> !heap -i 3d0000
Heap context set to the heap 0x003d0000
0:000> !heap -i 003dc708
Detailed information for block entry 003dc708
Assumed heap : 0x003d0000 (Use !heap -i NewHeapHandle to change)
Header content : 0x6334FAFC 0x0D00FD4A (decoded : 0x61010262 0x0D000008)
Owning segment : 0x003d0000 (offset 0)
Block flags : 0x1 (busy )
Total block size : 0x262 units (0x1310 bytes)
Requested size : 0x1303 bytes (unused 0xd bytes)
Previous block size: 0x8 units (0x40 bytes)
Block CRC : OK - 0x61
Previous block : 0x003dc6c8
Next block : 0x003dda18
Related
``java.lang.VerifyError: Expecting a stackmap frame at branch target 146
Exception Details:
Location:
com/common/utilities/Payload(Ljava/lang/String;Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Object; #45: invokestatic
Reason:
Expected stackmap frame at this location.
Bytecode:
0000000: 2a3a 082b 3a09 2c3a 0ab2 0155 0101 06bd
0000010: 0051 3a07 1907 0319 0853 1907 0419 0953
0000020: 1907 0519 0a53 1907 b801 5b3a 06b8 0161
0000030: 1906 b601 65b2 0002 1203 b600 04b2 0005
0000040: 2aba 0006 0000 4eb2 0007 2bb6 0008 bb00
0000050: 0959 2d03 bd00 09b8 000a b800 0bb7 000c
0000060: 3a04 1904 b800 0d3a 0519 052b b900 0e02
0000070: 00b8 000f 2cb8 0010 3a0c a700 253a 04b2
0000080: 0002 1904 b600 1219 04b6 0013 013a 0ca7
0000090: 0010 3a0b b801 6119 0bb6 0169 190b bfb8
00000a0: 0161 b601 6c19 0cb0
Exception Handler Table:
bci [78, 120] => handler: 125
bci [45, 146] => handler: 146`
I tried googling them separately, but one thing stuck out the most. Is it just that IAT is for PE files and GoT is for ELF?
Is it just that IAT is for PE files and GoT is for ELF?
This is the main difference.
Another difference is that the GOT in ELF files may also contain entries describing symbols defined in the ELF file itself. This is typical for 32-bit shared libraries.
IATs in PE files contain only entries that describe symbols defined in other DLL files.
On Linux, the nm command can be used to see all symbols that must be imported from shared libraries. I compiled a small program called "main". Using the nm command, I can see the offsets of objects. Symbols prefixed with a 'T' are functions can be found in the "main" code, along with logical offset (Global Offset Table). Symbols prefixed with a 'U' are undefined, and must be imported (Import Address Table).
$ nm main
0000000100000d70 T _AddAlbum
U ___error
U ___stderrp
0000000100000000 T __mh_execute_header
U _fprintf
0000000100000e40 T _main
U _malloc
U _printf
U _realloc
U _strerror
U dyld_stub_binder
For more detail, use the objdump with the -x option:
$ objdump -x main
main: file format Mach-O 64-bit x86-64
Sections:
Idx Name Size Address Type
0 __text 0000018a 0000000100000d70 TEXT
1 __stubs 00000024 0000000100000efa TEXT
2 __stub_helper 0000004c 0000000100000f20 TEXT
3 __cstring 00000042 0000000100000f6c DATA
4 __unwind_info 00000048 0000000100000fb0 DATA
5 __nl_symbol_ptr 00000008 0000000100001000 DATA
6 __got 00000010 0000000100001008 DATA
7 __la_symbol_ptr 00000030 0000000100001018 DATA
SYMBOL TABLE:
0000000100000d70 g F __TEXT,__text _AddAlbum
0000000100000000 g F __TEXT,__text __mh_execute_header
0000000100000e40 g F __TEXT,__text _main
0000000000000000 *UND* ___error
0000000000000000 *UND* ___stderrp
0000000000000000 *UND* _fprintf
0000000000000000 *UND* _malloc
0000000000000000 *UND* _printf
0000000000000000 *UND* _realloc
0000000000000000 *UND* _strerror
0000000000000000 *UND* dyld_stub_binder
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL LIB64 EXECUTE 15 1296 NOUNDEFS DYLDLINK TWOLEVEL PIE
Load command 0
cmd LC_SEGMENT_64
cmdsize 72
segname __PAGEZERO
vmaddr 0x0000000000000000
vmsize 0x0000000100000000
fileoff 0
filesize 0
maxprot ---
initprot ---
nsects 0
flags (none)
Load command 1
cmd LC_SEGMENT_64
cmdsize 472
segname __TEXT
vmaddr 0x0000000100000000
vmsize 0x0000000000001000
fileoff 0
filesize 4096
maxprot r-x
initprot r-x
nsects 5
flags (none)
Section
sectname __text
segname __TEXT
addr 0x0000000100000d70
size 0x000000000000018a
offset 3440
align 2^4 (16)
reloff 0
nreloc 0
type S_REGULAR
attributes PURE_INSTRUCTIONS SOME_INSTRUCTIONS
reserved1 0
reserved2 0
Section
sectname __stubs
segname __TEXT
addr 0x0000000100000efa
size 0x0000000000000024
offset 3834
align 2^1 (2)
reloff 0
nreloc 0
type S_SYMBOL_STUBS
attributes PURE_INSTRUCTIONS SOME_INSTRUCTIONS
reserved1 0 (index into indirect symbol table)
reserved2 6 (size of stubs)
Section
sectname __stub_helper
segname __TEXT
addr 0x0000000100000f20
size 0x000000000000004c
offset 3872
align 2^2 (4)
reloff 0
nreloc 0
type S_REGULAR
attributes PURE_INSTRUCTIONS SOME_INSTRUCTIONS
reserved1 0
reserved2 0
Section
sectname __cstring
segname __TEXT
addr 0x0000000100000f6c
size 0x0000000000000042
offset 3948
align 2^0 (1)
reloff 0
nreloc 0
type S_CSTRING_LITERALS
attributes (none)
reserved1 0
reserved2 0
Section
sectname __unwind_info
segname __TEXT
addr 0x0000000100000fb0
size 0x0000000000000048
offset 4016
align 2^2 (4)
reloff 0
nreloc 0
type S_REGULAR
attributes (none)
reserved1 0
reserved2 0
Load command 2
cmd LC_SEGMENT_64
cmdsize 312
segname __DATA
vmaddr 0x0000000100001000
vmsize 0x0000000000001000
fileoff 4096
filesize 4096
maxprot rw-
initprot rw-
nsects 3
flags (none)
Section
sectname __nl_symbol_ptr
segname __DATA
addr 0x0000000100001000
size 0x0000000000000008
offset 4096
align 2^3 (8)
reloff 0
nreloc 0
type S_NON_LAZY_SYMBOL_POINTERS
attributes (none)
reserved1 6 (index into indirect symbol table)
reserved2 0
Section
sectname __got
segname __DATA
addr 0x0000000100001008
size 0x0000000000000010
offset 4104
align 2^3 (8)
reloff 0
nreloc 0
type S_NON_LAZY_SYMBOL_POINTERS
attributes (none)
reserved1 7 (index into indirect symbol table)
reserved2 0
Section
sectname __la_symbol_ptr
segname __DATA
addr 0x0000000100001018
size 0x0000000000000030
offset 4120
align 2^3 (8)
reloff 0
nreloc 0
type S_LAZY_SYMBOL_POINTERS
attributes (none)
reserved1 9 (index into indirect symbol table)
reserved2 0
Load command 3
cmd LC_SEGMENT_64
cmdsize 72
segname __LINKEDIT
vmaddr 0x0000000100002000
vmsize 0x0000000000001000
fileoff 8192
filesize 572
maxprot r--
initprot r--
nsects 0
flags (none)
Load command 4
cmd LC_DYLD_INFO_ONLY
cmdsize 48
rebase_off 8192
rebase_size 8
bind_off 8200
bind_size 40
weak_bind_off 0
weak_bind_size 0
lazy_bind_off 8240
lazy_bind_size 96
export_off 8336
export_size 64
Load command 5
cmd LC_SYMTAB
cmdsize 24
symoff 8408
nsyms 11
stroff 8644
strsize 120
Load command 6
cmd LC_DYSYMTAB
cmdsize 80
ilocalsym 0
nlocalsym 0
iextdefsym 0
nextdefsym 3
iundefsym 3
nundefsym 8
tocoff 0
ntoc 0
modtaboff 0
nmodtab 0
extrefsymoff 0
nextrefsyms 0
indirectsymoff 8584
nindirectsyms 15
extreloff 0
nextrel 0
locreloff 0
nlocrel 0
Load command 7
cmd LC_LOAD_DYLINKER
cmdsize 32
name /usr/lib/dyld (offset 12)
Load command 8
cmd LC_UUID
cmdsize 24
uuid 55558635-5195-3609-B115-706912ED1DA7
Load command 9
cmd LC_BUILD_VERSION
cmdsize 32
platform macos
sdk 10.14
minos 10.14
ntools 1
tool ld
version 520.0
Load command 10
cmd LC_SOURCE_VERSION
cmdsize 16
version 0.0
Load command 11
cmd LC_MAIN
cmdsize 24
entryoff 3648
stacksize 0
Load command 12
cmd LC_LOAD_DYLIB
cmdsize 56
name /usr/lib/libSystem.B.dylib (offset 24)
time stamp 2 Wed Dec 31 17:00:02 1969
current version 1281.0.0
compatibility version 1.0.0
Load command 13
cmd LC_FUNCTION_STARTS
cmdsize 16
dataoff 8400
datasize 8
Load command 14
cmd LC_DATA_IN_CODE
cmdsize 16
dataoff 8408
datasize 0
I'm learning C programming and this is my problem. I feel like I've learned the macro topic in C but I guess I'm not quite ready yet.
#define PGSIZE 4096
#define CONVERT(sz) (((sz)+PGSIZE-1) & ~(PGSIZE-1))
printf("0x%x", CONVERT(0x123456));
Here is the problem. My expected output is 0x100000000000 but it prints 0x124000.
((sz)+PGSIZE-1) = (0x123456)+4096-1
= (0x123456)+(0x1000 0000 0000) - 1 //4096 is 2^12
= 0x1000 0012 3456 - 1
= 0x1000 0012 3455
~(PGSIZE-1) => ~(0x0111 1111 1111) = 0x1000 0000 0000
((sz)+PGSIZE-1) & ~(PGSIZE-1) = (0x1000 0012 3455) & (0x1000 0000 0000)
= 0x100000000000
But when I ran the program, it prints 0x124000.
What am I doing wrong?
You showed in the question:
((sz)+PGSIZE-1) => (0x123456)+4096-1
=(0x123456)+(0x1000 0000 0000) - 1 //4096 is 2^12
=0x1000 0012 3456 - 1
You converted 4096 to a binary notation, but then treat it as a hexadecimal number. That won't work. If you want to keep the hexadecimal notation, that's:
((sz)+PGSIZE-1) => (0x123456)+4096-1
=(0x123456)+(0x1000) - 1
=0x124456 - 1
Or converting both to binary, that's:
((sz)+PGSIZE-1) => (0x123456)+4096-1
=(0b1_0010_0011_0100_0101_0110)+(0b1_0000_0000_0000) - 1
= 0b1_0010_0100_0100_0101_0110 - 1
The error is in your calculation.
2^12 is not 1000 0000 0000, but 0001 0000 0000 0000.
The weights of binary begin as 2^0 which is one so 2^12 comes at 13th position so 4096 is 0x1000
If you use this for your manual calculation you will get 0x124000 as your answer.
The below calculation also answers your doubt "how 0x124455 & 1000 becomes 0x124000? Does if automatically fill 1s to the front? Could you explain little more about it on the question?" in the comment of the previous answer.
4096 = 0x1000
4096-1 => 0xfff => 0x0000 0fff
~(4096-1) is thus 0xfffff000
Coming to the addition part in macro
(0x123456)+4096-1
=>0x123456+0x1000-1
=>0x124456-1
=>0x124455
You result will be 0x124455 & 0xfffff000 which is 0x124000 which is the correct output
In CC2541 (IAR EW51/7.20) project I need to store few large const arrays (~30KB each).
I define the first array:
const uint8 demo_signal_1[30000] = {
0X00,
0X01,
0X10,
// rest of the data
};
It links in XDATA_ROM_C segment and runs just fine.
Then I add another 30KB array in another segment to overcome 32KB limitation:
const uint8 demo_signal_2[30000] = {
0X22,
0X33,
0X44,
// rest of data
}
The linker throws an error:
Error[e104]: Failed to fit all segments into specified ranges. Problem discovered in segment XDATA_ROM_C. Unable to place 96 block(s) (0xe37e byte(s) total) in 0x8000 byte(s) of memory.
Can anyone guide how to locate the second array on its own segment so linking should pass ?
I tried to follow the documentation and the forum but I seem to fail grasp something.
many thanks for any support
Thanks.
UPDATE (pretty long but please bear with me):
I played a little with segments definitions -
I've added two new (CONST)segments to the xcl file:
// Define segments for const data in flash.
// First the segment with addresses as used by the program (flash mapped as XDATA)
-P(CONST)XDATA_ROM_C=0x8000-0xFFFF
-Z(CONST)XDATA_ROM_C2=0x28000-0x2FFFF // Added
-Z(CONST)XDATA_ROM_C3=0x38000-0x3FFFF // Added
//
And defined the arrays to locate in these segments
// Array 1 in it own segment
const uint8 demo_signal_1[28800] # "XDATA_ROM_C2"= {
0X00,
0X00,
0X01,
0X01,
// ...rest of initialization data
}
// Array 2 in it own segment
const uint8 demo_signal_2[28800] # "XDATA_ROM_C3" = {
0X00,
0X00,
0X02,
0X02,
// ...rest of initialization data
}
This time it does link fine and generate the following map file
****************************************
* *
* SEGMENTS IN ADDRESS ORDER *
* *
****************************************
SEGMENT SPACE START ADDRESS END ADDRESS SIZE TYPE ALIGN
======= ===== ============= =========== ==== ==== =====
INTVEC CODE 00000000 - 00000085 86 com 0
CSTART CODE 00000086 - 00000136 B1 rel 0
BIT_ID CODE 00000137 dse 0
BDATA_ID CODE 00000137 dse 0
IDATA_ID CODE 00000137 dse 0
IXDATA_ID CODE 00000137 dse 0
PDATA_ID CODE 00000137 dse 0
DATA_ID CODE 00000137 dse 0
XDATA_ID CODE 00000137 - 0000057A 444 rel 0
BANK_RELAYS CODE 0000057B - 0000151C FA2 rel 0
RCODE CODE 0000151D - 00001C4F 733 rel 0
CODE_N CODE 00001C50 dse 0
DIFUNCT CODE 00001C50 dse 0
NEAR_CODE CODE 00001C50 - 00002C14 FC5 rel 2
<BANKED_CODE> 1 CODE 00002C15 - 00002C17 3 rel 0
<BANKED_CODE,CODE_C> 1
CODE 00002C18 - 00007FFB 53E4 rel 2
<BANKED_CODE,XDATA_ROM_C_FLASH> 1
CODE 00008000 - 0000FFFD 7FFE rel 2
<BANKED_CODE> 2 CODE 00010000 - 00017FF9 7FFA rel 0
<BANKED_CODE> 3 CODE 00018000 - 0001DE08 5E09 rel 0
BLENV_ADDRESS_SPACE
CODE 0003E800 - 0003F7FF 1000 rel 0
REGISTERS DATA 00000000 - 00000007 8 rel 0
VREG DATA 00000008 - 00000017 10 rel 0
PSP DATA 00000018 dse 0
XSP DATA 00000018 - 00000019 2 rel 0
DATA_I DATA 0000001A dse 0
BREG BIT 00000020.0 - 00000020.7 8 rel 0
DATA_Z DATA 00000021 - 00000028 8 rel 0
SFR_AN DATA 00000080 - 00000080 1 rel 0
DATA 00000086 - 0000008A 5
DATA 0000008C - 0000008D 2
DATA 00000090 - 00000091 2
DATA 00000094 - 00000097 4
DATA 0000009A - 000000A9 10
DATA 000000AB - 000000AF 5
DATA 000000B3 - 000000B4 2
DATA 000000B6 - 000000B6 1
DATA 000000B8 - 000000B9 2
DATA 000000BB - 000000C7 D
DATA 000000C9 - 000000C9 1
DATA 000000D1 - 000000DB B
DATA 000000E1 - 000000E9 9
DATA 000000F1 - 000000F5 5
DATA 000000F8 - 000000FA 3
DATA 000000FC - 000000FF 4
XSTACK XDATA 00000001 - 00000280 280 rel 0
XDATA_Z XDATA 00000281 - 00000BE4 964 rel 0
XDATA_I XDATA 00000BE5 - 00001028 444 rel 0
<XDATA_N> 1 XDATA 00001029 - 00001C2A C02 rel 0
XDATA_AN XDATA 0000780E - 00007813 6 rel 0
<XDATA_ROM_C> 1 CONST 00008000 - 00008805 806 rel 2
XDATA_ROM_C2 XDATA 00028000 - 0002F07F 7080 rel 0
XDATA_ROM_C3 XDATA 00038000 - 0003F07F 7080 rel 0
IDATA_I IDATA 00000029 dse 0
IDATA_Z IDATA 00000029 - 0000002A 2 rel 0
ISTACK IDATA 00000040 - 000000FF C0 rel 0
****************************************
* *
* END OF CROSS REFERENCE *
* *
****************************************
126 461 bytes of CODE memory
34 bytes of DATA memory (+ 86 absolute )
7 210 bytes of XDATA memory (+ 6 absolute )
194 bytes of IDATA memory
8 bits of BIT memory
59 654 bytes of CONST memory
Errors: none
Warnings: none
Two observations (scroll to the bottom of the map file):
The CODE size reduced by the 28803 bytes as the size of the original
array located in the original segment, similarly
segment size reduced by same 28803 bytes. and;
Newly added CONST segment (in xcl file) appear as XDATA in the map file
This all would be fine if I could download the generated binary into the chip, but when I try to 'download and debug' I receive the following message:
Fatal Error: Everything you want to place in flash memory must be placed with Xlink CODE memory segment type.
I tried to circumvent and generate intel-extended hex file to flash it standalone but the IDE returns the following error:
Error[e133]: The output format intel-extended cannot handle multiple address spaces. Use format variants (-y -O) to specify which address space is wanted
Reaching so far I tried one more thing and changed the new segments definition to (CODE) as advised by the error message.
// Define segments for const data in flash.
// First the segment with addresses as used by the program (flash mapped as XDATA)
-P(CONST)XDATA_ROM_C=0x8000-0xFFFF
-Z(CODE)XDATA_ROM_C2=0x28000-0x2FFFF // Modified to (CODE)
-Z(CODE)XDATA_ROM_C3=0x38000-0x3FFFF // Modified to (CODE)
Once again it links fine and the map file shows (scroll to the bottom):
****************************************
* *
* SEGMENTS IN ADDRESS ORDER *
* *
****************************************
SEGMENT SPACE START ADDRESS END ADDRESS SIZE TYPE ALIGN
======= ===== ============= =========== ==== ==== =====
INTVEC CODE 00000000 - 00000085 86 com 0
CSTART CODE 00000086 - 00000136 B1 rel 0
DATA_ID CODE 00000137 dse 0
BDATA_ID CODE 00000137 dse 0
BIT_ID CODE 00000137 dse 0
IDATA_ID CODE 00000137 dse 0
IXDATA_ID CODE 00000137 dse 0
PDATA_ID CODE 00000137 dse 0
XDATA_ID CODE 00000137 - 0000057A 444 rel 0
BANK_RELAYS CODE 0000057B - 0000151C FA2 rel 0
RCODE CODE 0000151D - 00001C4F 733 rel 0
DIFUNCT CODE 00001C50 dse 0
CODE_N CODE 00001C50 dse 0
NEAR_CODE CODE 00001C50 - 00002C14 FC5 rel 2
<BANKED_CODE> 1 CODE 00002C15 - 00002C17 3 rel 0
<BANKED_CODE,CODE_C> 1
CODE 00002C18 - 00007FFB 53E4 rel 2
<BANKED_CODE,XDATA_ROM_C_FLASH> 1
CODE 00008000 - 0000FFFD 7FFE rel 2
XDATA_ROM_C2 CODE 00010000 - 0001707F 7080 rel 0
<BANKED_CODE> 2 CODE 00017080 - 00017FF3 F74 rel 0
XDATA_ROM_C3 CODE 00018000 - 0001F07F 7080 rel 0
<BANKED_CODE> 3 CODE 0001F080 - 0001FFF0 F71 rel 0
<BANKED_CODE> 4 CODE 00020000 - 00027FF9 7FFA rel 0
<BANKED_CODE> 5 CODE 00028000 - 0002BF23 3F24 rel 0
BLENV_ADDRESS_SPACE
CODE 0003E800 - 0003F7FF 1000 rel 0
REGISTERS DATA 00000000 - 00000007 8 rel 0
VREG DATA 00000008 - 00000017 10 rel 0
PSP DATA 00000018 dse 0
XSP DATA 00000018 - 00000019 2 rel 0
DATA_I DATA 0000001A dse 0
BREG BIT 00000020.0 - 00000020.7 8 rel 0
DATA_Z DATA 00000021 - 00000028 8 rel 0
SFR_AN DATA 00000080 - 00000080 1 rel 0
DATA 00000086 - 0000008A 5
DATA 0000008C - 0000008D 2
DATA 00000090 - 00000091 2
DATA 00000094 - 00000097 4
DATA 0000009A - 000000A9 10
DATA 000000AB - 000000AF 5
DATA 000000B3 - 000000B4 2
DATA 000000B6 - 000000B6 1
DATA 000000B8 - 000000B9 2
DATA 000000BB - 000000C7 D
DATA 000000C9 - 000000C9 1
DATA 000000D1 - 000000DB B
DATA 000000E1 - 000000E9 9
DATA 000000F1 - 000000F5 5
DATA 000000F8 - 000000FA 3
DATA 000000FC - 000000FF 4
XSTACK XDATA 00000001 - 00000280 280 rel 0
XDATA_Z XDATA 00000281 - 00000BE4 964 rel 0
XDATA_I XDATA 00000BE5 - 00001028 444 rel 0
<XDATA_N> 1 XDATA 00001029 - 00001C2A C02 rel 0
XDATA_AN XDATA 0000780E - 00007813 6 rel 0
<XDATA_ROM_C> 1 CONST 00008000 - 00008805 806 rel 2
IDATA_I IDATA 00000029 dse 0
IDATA_Z IDATA 00000029 - 0000002A 2 rel 0
ISTACK IDATA 00000040 - 000000FF C0 rel 0
****************************************
* *
* END OF CROSS REFERENCE *
* *
****************************************
184 061 bytes of CODE memory
34 bytes of DATA memory (+ 86 absolute )
7 210 bytes of XDATA memory (+ 6 absolute )
194 bytes of IDATA memory
8 bits of BIT memory
2 054 bytes of CONST memory
Errors: none
Warnings: none
Voilla, CONST has shrunk and CODE expanded by exactly 57600 bytes as expected.
It even download and debug and generates hex file.
BUT when debugging the code it appears that instead of accessing 0x28000/0x38000, the memory controller access the data at 0x8000 which is the 'original' (CONST)XDATA_ROM_C segment.
To summarize:
when defining the two new segments as (CONST), the code links but can not debug nor generate hex file and
when defining the two new segments as (CODE), the code links, loads and run but the memory is not accessed correclty.
phew, this was long description. Any ideas someone ????
Note that this thread is duplicated at TI e2e forum as well here
I have the same problem. Seems all data constants need to be in a single 32K segment that gets mapped into the Xdata region. I did a weak work around by using the -Z(CODE)XDATA_ROM_C2=0x38000-0x3FFFF declaration in your second attempt to map my 2nd array of 32K data into BANK6. In my code access routine I cheated by using the HalFlashRead routine to pull 32 bytes chunks into a local array and then index into the local array -- lots of bits missing, but the HaFlash routine expects a 2k page number, offset into page, buffer to place the data, and byte count. This is hardly a solid portable solution but allowed me to move forward. -- hope it helps or gives you more insight
rd_addr = 0x38000 + offset;
HalFlashRead((rd_addr>>0x11)&0xff), (rd_addr & 0x7ff), *ptr32bytes, 32);
realdata = ptr[0]; // offset == [0], offset+1= [1], ....
This question already has an answer here:
SIZE command in UNIX
(1 answer)
Closed 7 years ago.
In this program i am not declaring any variable still is showing data segment (BSS) size as 8 bytes.why ?
achul#achul:~/chennai/misclaneous$ vi memory.c
#include<stdio.h>
main()
{
}
achul#achul:~/chennai/misclaneous$ cc memory.c -o mem
achul#achul:~/chennai/misclaneous$ size mem
text data bss dec hex filename
1056 252 8 1316 524 mem
here i am not using any global variable as BSS is reserved for global variable only anyone plz ?
In a normal (hosted) environment, the .c files and compiled to object files, and this object files are linked with the standard clib. And the library contains a module (generally called crt0.o) that is natively loaded by the system, optionnaly decodes the command line and calls the function main passing argc, argv and environment, and also generally sets some global variables.
This crt0 module does contain global variables.
Here are couple of outputs
Below is a compiled object and not at all linked, purely the simple program above with no global content as indicated.
size t1.o
text data bss dec hex filename
62 0 0 62 3e t1.o
size --format=SysV t1.o
t1.o :
section size addr
.text 6 0
.data 0 0
.bss 0 0
.comment 42 0
.note.GNU-stack 0 0
.eh_frame 56 0
Total 104
And this Below is a complete executable likned with startup code and other supported stuff.
size a.out
text data bss dec hex filename
1115 552 8 1675 68b a.out
size --format=SysV a.out
a.out :
section size addr
.interp 28 4194872
.note.ABI-tag 32 4194900
.note.gnu.build-id 36 4194932
.gnu.hash 28 4194968
.dynsym 72 4195000
.dynstr 56 4195072
.gnu.version 6 4195128
.gnu.version_r 32 4195136
.rela.dyn 24 4195168
.rela.plt 48 4195192
.init 26 4195240
.plt 48 4195280
.text 370 4195328
.fini 9 4195700
.rodata 4 4195712
.eh_frame_hdr 52 4195716
.eh_frame 244 4195768
.init_array 8 6295056
.fini_array 8 6295064
.jcr 8 6295072
.dynamic 464 6295080
.got 8 6295544
.got.plt 40 6295552
.data 16 6295592
.bss 8 6295608
.comment 77 0
Total 1752