[PATCH] gdb: add support for handling core dumps on arm-none-eabi

[Fredrik Hederstierna]

> From: Simon Marchi <simark@simark.ca>
> Sent: Tuesday, October 20, 2020 5:04 PM
> To: Fredrik Hederstierna <fredrik.hederstierna@verisure.com>; Paul Mathieu <paulmathieu@google.com>
> Cc: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Luis Machado <luis.machado@linaro.org>; Alan Hayward > <Alan.Hayward@arm.com>
> Subject: Re: [PATCH] gdb: add support for handling core dumps on arm-none-eabi 
 
> Ok, thanks for trying.  Is Outlook's SMTP not really SMTP?

I think git-email now works with the SMTP server, but need to learn how to embed message etc. sorry for beginners mistakes..

> One warning to fix we get when applying:
>
> Applying: gdb: Support corefiles for arm-none-eabi
> .git/rebase-apply/patch:703: trailing whitespace.

I found one place with trailing whitespace that I missed, should be fixed.

> One thing that doesn't look right is this, in none_make_corefile_notes:
>
>      int global_id = 1;
>      struct thread_info *info = find_thread_global_id (global_id);
>
> As you might have noticed, GDB now supports being connected to multiple
> targets at the same time.  So, inferior 1 could be a local GNU/Linux
> executable, while inferior 2 could be a remote bare-metal ARM program.


> If so, I guess GDB should just dump all the current inferior's threads
> in the core dump.

I've tried to modify code so it should dump all threads,
created a [PATCH v2] which includes this (sent with git-email).

> I see you have this commented out:
>
>    /* make_cleanup (xfree, note_data); */
>
> The way to do it now would be to make note_data a
> gdb::unique_xmalloc_ptr<char>, and do "return note_data.release ();"
> when returning.  This way, it gets automatically freed if something bad
> happens.  And ideally, gdbarch_make_corefile_notes should be changed to
> return a gdb::unique_xmalloc_ptr<char>, but that's out of the scope of
> this patch (I'll give it a quick try).

I tried to copy linux-tdep.c, and I could not find where data is unallocated, but maybe its a later problem.

> You don't need an _initialize_none_tdep if you don't do anything in it.

Ok, I kept if for now, if something pops up that needs to be put there along the road..

> One last question: I see that you deal with AUXV stuff.  Will bare-metal
> arm programs really have an auxiliary vector?

I'm not sure what Auxv contains, but seems to be eg some system info that is handy, I do not know what/if its filled with something by default on a bare-metal arm-none target/arch?

Thanks! BR Fredrik