Using the pad segment as a split that doesn't match the alignment parameters will generate even more space than it should.
I haven't investigated or tested deeply into the issue so maybe I'm missing something. To give an idea I will explain it in other way, relative to the issue we are experiencing:
First, lets stablish that we have an alignment of 4, so then in this case we have this data:
[0x5004, bss, idk1]
[0x500C, bss, idk2]
In our case there is actually something used at 0x5008, but from 0x5009 to 0x500C there is garbage data (likely generated by the linker) so naturally we would do this:
[0x5004, bss, idk1]
[0x5009, pad] # garbage data
[0x500C, bss, idk2]
However this clashes with the linker for some reason the linker will generate more padding pushing the next data further.
If then we remove the pad segment we assigned from the linker script generated by splat manually this get fixed.
Using the
padsegment as a split that doesn't match the alignment parameters will generate even more space than it should.I haven't investigated or tested deeply into the issue so maybe I'm missing something. To give an idea I will explain it in other way, relative to the issue we are experiencing:
First, lets stablish that we have an alignment of 4, so then in this case we have this data:
In our case there is actually something used at
0x5008, but from0x5009to0x500Cthere is garbage data (likely generated by the linker) so naturally we would do this:However this clashes with the linker for some reason the linker will generate more padding pushing the next data further.
If then we remove the pad segment we assigned from the linker script generated by splat manually this get fixed.