Thoughts on the problem of Csapp lab3 in middle pressure stack

There was a question and no special attention, I came back today to see the mail found that some classmates and I discuss the function call stack problem.

Talk less, directly on the comparison test chart:

Figure one: Csapp Lab3 's Getbuf disassembly results

Figure II: I tested, excerpt part of the GETBUF implementation, and then very simple to test the Getbuf disassembly results, disassembly results such as

How on earth did I test it:

unsigned long long getbuf () {  char buf[36];  Volatile char* variable_length;  int i;  unsigned long long Val;  return val% 40;} int main () {    getbuf ();    return 0;}

Individuals still feel that the test code is not a problem. The main thing is to observe how the BUF array is compressed. Preserving the other local variables is possible, theoretically without affecting the size of the new stack that the ESP self-decrement opens.

But ... but.

Q1:

Children's shoes can be clearly seen here the results of the two disassembly are different.

The former opens up the 0x30 size of the stack frame

The latter opened up the 0x40 size of the stack frame.

Q2:

Using Csapp's executable program, GDB debugs and then looks at the disassembler.

Observe the address of the register RBP and BUF.

That is, buf array distance from the stack base address (RBP register point), the difference between the size of 0x30.

There should be only buf array elements in this area, and no other variables or registers are pressed to stack. So I suspect this buf array (originally only 36byte) is aligned to 48byte (0x30), but this is not explained, because if you follow the 64-bit operating system, 8byte alignment, as long as the alignment to

0x28 on it, no 0x30. The difference between the 8byte here is a question.

There is a master passing, implore guidance ...

Thoughts on the problem of Csapp lab3 in middle pressure stack