Error: segments out of order - (1060 starts at 0x1060, but next segment starts at 0x1010)

[alan-barzilay]

I was trying to split my tony hawk pro skater n64 ROM But got the following error: Error: segments out of order - (1060 starts at 0x1060, but next segment starts at 0x1010)

I was following the quick start and ran create_config and then the split command. I understand that I should iterate and work on the configuration file, but I thought that the command would give me something barebones but that worked. Was I mistaken or have I stumbled upon a bug?

here's the config file I generated:

sha1: fc1b4dec85e6874fa7321edc24f5a1e78600d9d0
options:
  basename: tonyhawkproskater
  target_path: Tony Hawk's Pro Skater (USA).z64
  elf_path: build/tonyhawkproskater.elf
  base_path: .
  platform: n64
  compiler: GCC

  # asm_path: asm
  # src_path: src
  # build_path: build
  # create_asm_dependencies: True

  ld_script_path: tonyhawkproskater.ld
  ld_dependencies: True

  find_file_boundaries: True
  header_encoding: ASCII

  o_as_suffix: True
  use_legacy_include_asm: False
  mips_abi_float_regs: o32

  asm_function_macro: glabel
  asm_jtbl_label_macro: jlabel
  asm_data_macro: dlabel

  # section_order: [".text", ".data", ".rodata", ".bss"]
  # auto_link_sections: [".data", ".rodata", ".bss"]

  symbol_addrs_path:
    - symbol_addrs.txt
  reloc_addrs_path:
    - reloc_addrs.txt

  # undefined_funcs_auto_path: undefined_funcs_auto.txt
  # undefined_syms_auto_path: undefined_syms_auto.txt

  extensions_path: tools/splat_ext

  # string_encoding: ASCII
  # data_string_encoding: ASCII
  rodata_string_guesser_level: 2
  data_string_guesser_level: 2
  # libultra_symbols: True
  # hardware_regs: True
  # gfx_ucode: # one of [f3d, f3db, f3dex, f3dexb, f3dex2]
segments:
  - name: header
    type: header
    start: 0x0

  - name: boot
    type: bin
    start: 0x40

  - name: entry
    type: code
    start: 0x1000
    vram: 0x80000400
    subsegments:
      - [0x1000, hasm]

  - name: main
    type: code
    start: 0x1060
    vram: 0x80000460
    follows_vram: entry
    bss_size: 0x0
    subsegments:
      - [0x1060, asm]
      - [0x1010, data]
      - { start: 0x139E4, type: bss, vram: 0x80012DE4 }

  - type: bin
    start: 0x139E4
    follows_vram: main
  - [0xC00000]

ps: How does splat infer the compiler? I was dreading having to uncover that, but knowing that it was GCC should help a lot.

[ethteck]

Ahh, yeah, this does look like a bug. Thanks for the report! I'd get rid of the data subsegment there and see what happens. If you're used to looking at mips, it should be pretty clear when actual code stops.

As for gcc vs ido, gcc uses j for branching, and ido uses b. So it's easy to know if you're ido vs gcc. To narrow it down further, usually some trial and error is needed.

[alan-barzilay]

Thanks for the quick response! Deleting the data subsegment stop the crashes:

Scanning 139E4: 100%|████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 5/5 [00:00<00:00, 92.59it/s]
Splitting 139E4: 100%|███████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 5/5 [00:00<00:00, 13.36it/s]
Linker script 139E4: 100%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████| 5/5 [00:00<00:00, 2010.50it/s]
Split 80 KB (0.64%) in defined segments
              header:     64 B (0.00%) 1 split, 0 cached
                 bin:     4 KB (0.03%) 1 split, 0 cached
                code:    76 KB (0.61%) 2 split, 0 cached
             unknown:    12 MB (99.36%) from unknown bin files

is 99.36% common for unknown segments on a first run?
I'm starting to dread the journey ahead haha

If you're used to looking at mips, it should be pretty clear when actual code stops.

Sadly I have never worked with mips before, I have been a programmer for many years but this is my first real adventure with assembly and reverse engineering.

Any tips for a new comer? I'm just trying to wet my feet by modding some simple retexturing and switching the game music, my idea was to split the rom to find out were the textures and other data are located.

[mkst]

Maybe join the decomp.me discord https://discord.gg/sutqNShRRs?

The images in the ROM are unlikely to have headers so it probably isn't trivial to identify all the textures

[mkst]

This is not a bug. Perhaps the error text could be clearer? It's unlikely to be able to point to the line of the yaml though I guess 😕

    subsegments:
      - [0x1060, asm]
      - [0x1010, data] # 0x1010 is lower than 0x1060

[ethteck]

The bug is that (presumably) the create config script generated this - something in the code vs data detection

[AngheloAlf]

This seems to be an issue with the entrypoint parsing of the create_config script. The entrypoint of this game is not a "traditional" one, so splat chokes at trying to infer information from it.
I'm working on a fix so create_config can properly get the information from this kind of entrypoint. I'll also try to make create_config to not generate out of order segments.