Feature Request: Wildcards in segment/section mapping
nitz opened this issue · 5 comments
Hello! Fantastic tool!
I'm using it with Microchip's XC16 complier, and having a lot of success in tracking down what's using my memory. On this 16-bit complier specifically though, for everything addressed above 0x8000 in memory, I need to access it through their "EDS" window. In order to do that, I flag variables to be placed there with an attribute. when the complier generates the sections, it specifies generated names for the variables I've placed there.
Here's an example of the data memory readout from the map:
"data" Memory [Origin = 0x1000, Length = 0xd000]
section address alignment gaps total length (dec)
------- ------- -------------- -------------------
.bss 0x1000 0 0x4232 (16946)
.data 0x5232 0 0x440 (1088)
.bss 0x5672 0 0x314 (788)
.data 0x5986 0 0xae (174)
.bss 0x5a34 0 0x4e (78)
.data 0x5a82 0 0x4c (76)
.bss 0x5ace 0 0x52 (82)
.data 0x5b20 0 0x26 (38)
.bss 0x5b46 0 0xe (14)
.data 0x5b54 0 0x8 (8)
.bss 0x5b5c 0 0x4 (4)
_000000000768F0A0601c1dc9 0xb300 0 0x2800 (10240)
_000000000770BE60601c1dc8 0xdb00 0 0x200 (512)
_000000000741A320601c1b9b 0xdd00 0 0x20 (32)
_000000000770BB40601c1dc8 0xdd80 0 0x200 (512)
_0000000007F9F280601c1dc5 0xdf80 0 0x80 (128)
Total "data" memory used (bytes): 0x7800 (30720) 57%
All of those sections starting with _000 are variables/functions placed in the EDS (above 0x8000) memory area. For teh time being, I'm manually adding each of those names to the BSSSeg2SecMap, but as I change things the complier likes to move them around. Being able to add a section named something like _00* would be fantastic to pick up all of those auto-generated segments!
Cheers again for the fantastic tool!
Thank you for the coffee :)
I think this is probably not too difficult to do. Could you share your MAP/ELF file for testing? However for now there is no option to define custom sections other than the built-in Text/Data/BSS. So you can't separate out the EDS contents in the view.
Yep! I'll whip you up a map & elf shortly!
Yeah the distinction of EDS is really pretty irrelevant to me for now (and in fact, only had to fight with it because I realized I was pushing up against that boundary and getting linker errors til I moved some large arrays into it! Like that one at 0xb300) I was just treating it as BSS data, because assuming it was zeroed was enough for my quick checks.
I actually noticed in your article here, (which is how I ever even found your tool a while back!) You mentioned your default list of section names were based on the PIC24, which explains why it has worked so well for me, being on a dsPIC33!
I'm not sure if you actually have any of Microchip's compilers installed at the moment, but if you do, the way to ask it to put some data in the "EDS" area is like this:
uint8_t __eds__ my_random_buffer[2048] __attribute__((eds, page)) = { 0 };
^. tells compiler to use the eds window ^.
registers to access this variable `- the attribute "eds" is what puts the memory in that area.
"page" just says don't allow this variable to
span page boundariesI will see if I can remote in to my work machine and get you an elf/map in a few hours here. Thanks again!
Looking at the code again, I see that although the pattern matching can be updated easily enough, it creates other issues as the code tries to keep track of the elements in each section. Using wildcards will mean that all the related variables have to be put into one "unified" section - not a trivial change. Instead of trying to fix it here, could you try allocating all the EDS data inside a custom named section?
Something like the below might work?
__attribute__((section("my_eds_section_name")))
So, I duplicated the default linker and added my own section starting where EDS starts, thinking I needed to declare the section, reducing the size of the regular data region, and that displeased the linker greatly. I'm definitely not too great at understanding exactly what it expects between the complier and linker and hardware, but that's an adventure for another day for me.
I stuck my larger array with the section attribute. Looks like putting it on a extern decl. causes issues but on the declaration/definition itself it named it: (I used the name 'himem', as an old dos throwback.)
"data" Memory [Origin = 0x1000, Length = 0xd000]
section address alignment gaps total length (dec)
------- ------- -------------- -------------------
.bss 0x1000 0 0x4232 (16946)
.data 0x5232 0 0x440 (1088)
.bss 0x5672 0 0x32a (810)
.data 0x599c 0 0xae (174)
.bss 0x5a4a 0 0x4e (78)
.data 0x5a98 0 0x4c (76)
.bss 0x5ae4 0 0x52 (82)
.data 0x5b36 0 0x26 (38)
.bss 0x5b5c 0 0xe (14)
.data 0x5b6a 0 0x8 (8)
.bss 0x5b72 0 0x4 (4)
himem 0xb300 0 0x2800 (10240)
_00000000075C5E6060229b10 0xdb00 0 0x200 (512)
_0000000007CBD320602175fd 0xdd00 0 0x20 (32)
_00000000075C5B4060229b10 0xdd80 0 0x200 (512)
_000000000804B28060229bfd 0xdf80 0 0x80 (128)
Total "data" memory used (bytes): 0x7816 (30742) 57%
This certainly looks like it will be a valid workaround for this for now! 💖
Yeah I think you just have to name the section, the rest of the dirty work should be handled under the hood by the eds attribute you are already using. Glad it works!