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

Simon Marchi
2020-10-20T15:04:42Z

> Sorry my crappy corporate Outlook SMTP doesnt support me sending through git, and I had problems to using eg Google gmail,
> I try to attach the patch here and in the meantime try to solve this in a better way, sorry for the inconvenience.

Ok, thanks for trying. Is Outlook's SMTP not really SMTP?

One warning to fix we get when applying:

Applying: gdb: Support corefiles for arm-none-eabi
.git/rebase-apply/patch:703: trailing whitespace.

I'm leaving stylistic comments for later, it will be easier if you
succeed using git-send-email.

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.

So you can't assume that the thread you want to dump has global id 1.
You should get the current inferior with the current_inferior function,
and access its threads.

Also, if GDB connects to a remote target that is able to report the OS's
(FreeRTOS, for example) tasks as threads, is it possible to see them in
GDB? If I understand correctly this section of the OpenOCD manual,
OpenOCD can do it:

http://openocd.org/doc/html/GDB-and-OpenOCD.html#RTOS-Support

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

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).

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

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

Simon