Path changers - why we should be using argc/argv instead

Discussion in '3DS - Flashcards & Custom Firmwares' started by chaoskagami, Jun 22, 2016.

  1. chaoskagami
    OP

    chaoskagami Rawr

    Member
    1,026
    1,367
    Mar 26, 2016
    United States
    ↑↑↓↓←→←→BA
    Sort of a suggestion to homebrew devs, and I also want to pick some other developers' brains on standards.

    Right now, many A9LH-based CFWs need to know their location via a path changer and a static string within the program itself. Mostly for re-calling the payload via reboot patches.

    Using a path changer is messy for multiple reasons, including:

    * Not user friendly when using a boot manager.

    * Requires a string search which is a heuristic and can't necessarily be relied upon to be found in every program, and not always stored the same in it (char -> wchar_t conversion, arm9loaderhax.bin / arm9loaderhax_si.bin) as well as the possibility of overwriting an unrelated string.

    I propose that we switch over to using argc/argv passing, ideally stored after the arm9loaderhax payload somewhere in FCRAM. Then, payloads could simply use argv[0] to get their own path.

    I'm aware that I'm asking a lot. I don't expect anyone to do anything really, so this is more a suggestion. I just feel that it would be a much cleaner solution.

    It would allow not only argument passing but would obsolete path changers entirely, provide saner ways to enable and disable features...because it would allow calling programs like any other program on Linux, Windows, etc.

    I've personally implemented this into my CFW's chainloader. Take that as you will. Trashing r0 and r1 will work the same as before, regardless, because a no-argument main function doesn't check the arguments.

    EDIT: For a summary of what is involved in this, see my start.s file here: https://raw.githubusercontent.com/chaoskagami/corbenik/master/source/start.s

    It only requires saving r0 and r1 not to be trashed by the MPU setup, and reloading the registers prior to main.
     
    Last edited by chaoskagami, Jun 22, 2016
    gnmmarechal, Gray_Jack and Joel16 like this.
  2. MassExplosion213

    MassExplosion213 .

    Member
    1,433
    961
    Feb 15, 2015
    United States
    Chaos: How about using a particular "magic value" specific to your payload and scanning the SD for it? :P
     
  3. chaoskagami
    OP

    chaoskagami Rawr

    Member
    1,026
    1,367
    Mar 26, 2016
    United States
    ↑↑↓↓←→←→BA
    That's not a sane method for determining payload paths, because again, possible false positives. Aside from that, my CFW doesn't need a pathchanger.
     
    gnmmarechal likes this.
  4. MassExplosion213

    MassExplosion213 .

    Member
    1,433
    961
    Feb 15, 2015
    United States
    Large enough values are hard to get false positives of.
     
  5. chaoskagami
    OP

    chaoskagami Rawr

    Member
    1,026
    1,367
    Mar 26, 2016
    United States
    ↑↑↓↓←→←→BA
    You're missing the point here. With argc and argv - which are in use on every computer in existence by the way - it is 100% impossible to get false positives. Not to mention patterns again defeat the point here - which is to standardize a way for programs to recieve their own path (and arguments) without the need for overcomplicated and user-unfriendly hacks/tools.

    This is just a suggestion, anyways. It would make it easier for boot managers and chainloaders to provide data to programs. It's even used in userland with HBL, for that matter. There's no real reason not to do it.

    Like I said - programs can continue to not use the data and trash r0 and r1 on the processor with no ill effects.
     
    Last edited by chaoskagami, Jun 22, 2016
    gnmmarechal and Arcanuskun like this.
  6. Coto

    Coto GBAtemp Addict

    Member
    2,379
    418
    Jun 4, 2010
    Chile
    well ARM ABI itself defines r0-r3 as "scratchpad" registers for a reason, so the compiler would not put extremely valuable code there (such as a callee frame pointer).

    Now it's really up to the ABI to save frame context (r0-r3,r10,r11,lr)^ when a SWI exception occurs (namely because r0 is used as the SWI index for the software function index), so shouldn't be a problem
     
  7. chaoskagami
    OP

    chaoskagami Rawr

    Member
    1,026
    1,367
    Mar 26, 2016
    United States
    ↑↑↓↓←→←→BA
    I mean, this is coding 101 but cdecl convention mandates the first argument be in r0 and the second in r1. It definitely isn't an issue.

    It would be a few changes to start.s and the declaration of main, and programs would be able to get their path from any chainloader.
     
    Last edited by chaoskagami, Jun 22, 2016