Enable coredump generation for aarch64 and arm

[ss141309]

@rst0git can you please check this patch? Have I included all the relevant notes and registers? I was using the output of gcore to verify which notes need to be added. I will soon add the support for more architectures if this one is alright.
Thank you.

[ss141309]

@rst0git I am stuck while working on the loongarch64 architecture. The stack of the program does not seem to get saved in the coredump.

I am generating the coredump of this program:

static void func_2(void) {
  int var_2 = 2;
  while (1);
}

static void func_1(void) {
  int var_1 = 1;
  func_2();
}

static void func_0(void) {
  int var_0 = 0;
  func_1();
}

int main() {
  int var_main = -1;

  func_0();

  return 0;
}

and I am compiling it like this gcc -g -no-pie loop.c -o loop

when I open this coredump in gdb and execute bt full, it says

loongarch@debian:~/loop$ gdb ./loop core.19373
GNU gdb (Debian 16.2-1) 16.2
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "loongarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./loop...

warning: BFD: warning: /home/loongarch/loop/core.19373 has a segment extending past end of file

warning: malformed note - filename area is too big
[New LWP 19373]
Core was generated by `      '.
#0  func_2 () at loop.c:3
3         while (1);
(gdb) bt full
#0  func_2 () at loop.c:3
        var_2 = 0
#1  0x000000012000065c in func_1 () at loop.c:8
        var_1 = 0
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

the area of the memory where the stack pointer points is all 0s

(gdb) x/32x $sp
0x7ffffbfdc780: 0x00000000      0x00000000      0x00000000      0x00000000
0x7ffffbfdc790: 0x00000000      0x00000000      0x00000000      0x00000000
0x7ffffbfdc7a0: 0x00000000      0x00000000      0x00000000      0x00000000
0x7ffffbfdc7b0: 0x00000000      0x00000000      0x00000000      0x00000000
0x7ffffbfdc7c0: 0x00000000      0x00000000      0x00000000      0x00000000
0x7ffffbfdc7d0: 0x00000000      0x00000000      0x00000000      0x00000000
0x7ffffbfdc7e0: 0x00000000      0x00000000      0x00000000      0x00000000
0x7ffffbfdc7f0: 0x00000000      0x00000000      0x00000000      0x00000000

before dumping this program, I attached gdb to it, and examined the register values, all of the registers matched with the registers in the coredump, but there I could see the full backtrace, and the stack was not all zeroes.

what could be the problem here? I suspect it has to do something with the vmas, or is it something else?

Edit: also paging @avagin too for help with this issue

Thank You

[rst0git]

@ss141309 Thank you for working on this!

I am stuck while working on the loongarch64 architecture.

We can limit the scope of this pull request to aarch64 and armv7l. This will also make it easier for us to review and test the changes in the pull request.

[ss141309]

@ss141309 Thank you for working on this!

I am stuck while working on the loongarch64 architecture.

We can limit the scope of this pull request to aarch64 and armv7l. This will also make it easier for us to review and test the changes in the pull request.

ok, then I should make separate PRs for the other architectures?

[rst0git]

I should make separate PRs for the other architectures?

Sure, we can add coredump support for other architectures in a separate pull request.