← Back to context

Comment by actionfromafar

2 years ago

I must misunderstand something very basic about this code.

    if (pins[syscalls[i].sysno])

but pins is newly allocated and should just zero or "empty". Why dereference it right after allocation?

6 comments

actionfromafar

Reply
accessvector  2 years ago

Just to handle the case where the same syscall number is specified twice by the ELF header: in that case, the entry is set to -1 (presumably meaning it’s invalid).

  • actionfromafar  2 years ago

    I still don't get it. Shouldn't [9] always evaluate to false, and the code be equivalent to:

        pins = mallocarray(npins, sizeof(int), M_PINSYSCALL, M_WAITOK|M_ZERO);
    for (i = 0; i < nsyscalls; i++) {
        pins[syscalls[i].sysno] = syscalls[i].offset;
    }

    Edit:

    Hang on - npins is already checked in the loop before, and incremented with ++

    syscalls[i].sysno can't be larger than what is allocated with:

    pins = mallocarray(npins, sizeof(int), M_PINSYSCALL, M_WAITOK|M_ZERO);

    So I still can't find the problem

    • accessvector  2 years ago

      Consider this:

          struct pinsyscall entries[] = {
        { .sysno = 1, .offset = 0x1234 },
        { .sysno = 2, .offset = 0x5678 },
        { .sysno = 1, .offset = 0x9abc }
    };

      Now `nsyscalls` will be 3 and `pin` will be an array of 3 ints, initialised to `{ 0, 0, 0 }`.

      When we loop through, we'll set:

          1. `pin[syscalls[0].sysno] = 0x1234` => `pin[1] = 0x1234`
    2. `pin[syscalls[1].sysno] = 0x5678` => `pin[2] = 0x5678`

      Now when we come to 3, we'll find `pin[syscalls[2].sysno] != 0` since `syscalls[2].sysno == syscalls[0].sysno` - so we set `pin[1] = -1` instead of `0x9abc`.

      3 replies →