Hunk parsing issue when using VBCC

[ghost]

I compiled up a hello world application with vbcc (I'll upload a simple binary to dropbox)...

https://www.dropbox.com/s/24647vv97g3utd8/hello?dl=0

12:37:13.857 proc: ERROR: failed loading binary: Error loading '/home/stephen/compileZone/amitools/hello': Unsupported hunk type: 0000

I investigated this a bit and It seems to fail to parse a 1015 hunk (one it converts to 1020). It underreads the segment by 2 bytes so the f.read(4) on the next segment is not aligned to the start of the segment.

Hunkinfo parses this successfully as.... I wonder if its something to do with LoadSeg?

$ ./hunktool -d info hello
hello (0.0032s) TYPE_LOADSEG
header (segments: first=0, last=5, table size=6)
#000 CODE size 00000c54 alloc size 00000c54 file header @0000002c data @00000034
reloc drel32 #6
To Segment #0: 22 entries
To Segment #1: 36 entries
To Segment #2: 8 entries
To Segment #3: 2 entries
To Segment #4: 2 entries
To Segment #5: 43 entries
#1 DATA size 00000008 alloc size 0000003c file header @00000d8c data @00000d94
#2 DATA size 00000010 alloc size 00000010 file header @00000da0 data @00000da8
#3 DATA size 0000000c alloc size 0000000c file header @00000dbc data @00000dc4
reloc drel32 #1
To Segment #0: 1 entries
#4 DATA size 00000010 alloc size 00000010 file header @00000de0 data @00000de8
reloc drel32 #1
To Segment #0: 2 entries
#5 BSS size 00000018 alloc size 00000018 file header @00000e0c
RESULT_OK : 1

[ghost]

Issue is an incorrect mod ... this fixes the parser (but the code doesnt run correctly yet)...

index 017a141..7afb52b 100644
--- a/amitools/binfmt/hunk/HunkBlockFile.py
+++ b/amitools/binfmt/hunk/HunkBlockFile.py
@@ -195,7 +195,7 @@ class HunkRelocWordBlock(HunkBlock):
offsets.append(off)
self.relocs.append((hunk_num, offsets))
# pad to long

• if num_words % 1 == 1:
• if num_words % 2 == 1:
  self._read_word(f)

... seems to format badly but basically change line

if num_words % 1 == 1:

to

if num_words % 2 == 1:

in class HunkRelocWordBlock

[ghost]

Actually my fix does fix it. I was just missing ixemul.library.

[ghost]

So to be clear the change i posted works as follows..

There is a bit of code to ensure that we read an even number of words when reading a Reloc16 block. However the check has a mistake in it. NUM MOD 1 will always be zero. The check needs to be NUM MOD 2 to check for an odd number of reads. Its a really easy mistake to make actually.

[cnvogelg]

Thanks for spotting and reporting this really silly bug :)
Fixed in 5f772c2

[ghost]

confirmed this is fixed in latest pull.