Skip to content

Patches from zephyr-gdb-12.1 #17

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 8 commits into from
Jul 9, 2025
Merged

Patches from zephyr-gdb-12.1 #17

merged 8 commits into from
Jul 9, 2025

Conversation

@stephanosio
Copy link
Member

@stephanosio stephanosio commented Jul 8, 2025 •
edited
Loading

This series includes the patches from the zephyr-gdb-12.1 branch that are still relevant.

For more details, see zephyrproject-rtos/sdk-ng#941

EvgeniiDidin and others added 3 commits July 8, 2025 14:34
@EvgeniiDidin @stephanosio
gdb/remote: make tid/pid type long in write_ptid
8c2b9b6 
In Zephyr RTOS the k_thread_create function returns
thread ID which is actually pointer to k_thread structure.
If the memory addressing starts from 0x80000000, passing such
big values to write_ptid() leads to overflow of "int tid" variable
and thread ID becomes negative.
So lets make tid/pid variables type "long", this will prevent overflow
and should not break any logic.

Signed-off-by: Evgeniy Didin <didin@synopsys.com>
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
@lrgirdwo @stephanosio
gdb: Add fixes for stdint and remote debug on xtensa.
dc4655c 
Take both stdint and remote debug fixes from SOF.

Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
@dcpleung @stephanosio
gdb: xtensa: don't error out when registers cannot be read
3e93a45 
On Xtensa, some privileged registers cannot be read using 'p'
packet. So keep these marked as unavailable so GDB can still
fetch other registers instead of stopping at error.

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
@stephanosio stephanosio added the DNM label Jul 8, 2025
This was referenced Jul 8, 2025
Merged
Closed
dcpleung added 3 commits July 8, 2025 16:54
@dcpleung @stephanosio
gdb: xtensa: use remote target register numer...
0413fbc 
...instead of the sequential number defined in xtensa-config.c
when retrieving registers from remote target, as the remote
probe maps registers to their target numbers.

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
@dcpleung @stephanosio
gdb: arch to tell whether it supports 'g' packets
80c4169 
This adds a callback to gdbarch so indicate whether
the architecture supports 'g' packets to remote target.
For example, on Xtensa, xt-ocd does not support 'g'
packet. However, the register fetching code keeps on
trying 'g' packet which results in infinite loop. So
this provides a mechanism for architecture to indicate
whether 'g' packet is supported.

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
@dcpleung @stephanosio
gdb: xtensa: support disabling use of 'g' packet
3766b3a 
The xt-ocd from Xtensa's official toolchain may not support
'g' packet. So this allows building GDB which won't query
registers using 'g' packets but instead using 'p' packets only.

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
@stephanosio stephanosio force-pushed the gdb-16.2-oldpatches branch from 82c0e4c to 3766b3a Compare July 8, 2025 07:54
stephanosio and others added 2 commits July 8, 2025 20:51
@stephanosio
readline: Assume "unknown" terminal type by default
2e86a8e 
This patch modifies the `_rl_init_terminal_io` function to pass
`unknown` terminal type instead of `dumb` when no terminal name is
provided by the caller (e.g. when the `TERM` environment variable is
not set on Win32).

This ensures that the termcap provider (e.g. ncurses) resolves the
default preferred terminal type instead of using the `dumb` terminal
type.

Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
@MBODAPAT @stephanosio
microblaze: apply gdb patches from meta-xilinx repository
1a0efb6 
This patchset fixes many known issues on gnu-toolchain for microblaze.
But mainly the atomic-cas and binutils incorrect relocation issues. For gdb
this patchset resolves the segfault caused by inline-sniffer.

Patches obtained from https://github.com/xilinx/meta-xilinx/ repository,
from meta-microblaze/recipes-devtools/gdb/gdb path.
I've filtered out microblaze64 and microblaze-linux patches because they
cause microblaze-gdb to segfault at startup and more importantly,
unnecessary for Zephyr. Below is a list of patches applied and squashed:

0008-Patch-MicroBlaze.patch

Signed-off-by: Alp Sayin <alpsayin@gmail.com>
@stephanosio stephanosio removed the DNM label Jul 9, 2025
stephanosio
stephanosio commented Jul 9, 2025
View reviewed changes
Copy link
Member Author

@stephanosio stephanosio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested in https://github.com/zephyrproject-rtos/sdk-ng/actions/runs/16142549531?pr=959

@stephanosio stephanosio merged commit 6cae1a5 into zephyr-gdb-16.2 Jul 9, 2025
@stephanosio stephanosio deleted the gdb-16.2-oldpatches branch July 9, 2025 01:30
duynguyenxa pushed a commit to renesas/binutils-gdb that referenced this pull request Oct 29, 2025
@ssbssa
Prevent use-after-free of bfd filename in gdb_bfd_close_or_warn
820ebe4 
On Windows gcore is not implemented, and if you try it, you get an
heap-use-after-free error:

(gdb) gcore C:/gdb/build64/gdb-git-python3/gdb/testsuite/outputs/gdb.base/gcore-buffer-overflow/gcore-buffer-overflow.test
warning: cannot close "=================================================================
==10108==ERROR: AddressSanitizer: heap-use-after-free on address 0x1259ea503110 at pc 0x7ff6806e3936 bp 0x0062e01ed990 sp 0x0062e01ed140
READ of size 111 at 0x1259ea503110 thread T0
    #0 0x7ff6806e3935 in strlen C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:391
    zephyrproject-rtos#1 0x7ff6807169c4 in __pformat_puts C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:558
    zephyrproject-rtos#2 0x7ff6807186c1 in __mingw_pformat C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:2514
    zephyrproject-rtos#3 0x7ff680713614 in __mingw_vsnprintf C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_vsnprintf.c:41
    zephyrproject-rtos#4 0x7ff67f34419f in vsnprintf(char*, unsigned long long, char const*, char*) C:/msys64/mingw64/x86_64-w64-mingw32/include/stdio.h:484
    zephyrproject-rtos#5 0x7ff67f34419f in string_vprintf[abi:cxx11](char const*, char*) C:/gdb/src/gdb.git/gdbsupport/common-utils.cc:106
    zephyrproject-rtos#6 0x7ff67b37b739 in cli_ui_out::do_message(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/cli-out.c:227
    zephyrproject-rtos#7 0x7ff67ce3d030 in ui_out::call_do_message(ui_file_style const&, char const*, ...) C:/gdb/src/gdb.git/gdb/ui-out.c:571
    zephyrproject-rtos#8 0x7ff67ce4255a in ui_out::vmessage(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/ui-out.c:740
    zephyrproject-rtos#9 0x7ff67ce2c873 in ui_file::vprintf(char const*, char*) C:/gdb/src/gdb.git/gdb/ui-file.c:73
    zephyrproject-rtos#10 0x7ff67ce7f83d in gdb_vprintf(ui_file*, char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:1881
    zephyrproject-rtos#11 0x7ff67ce7f83d in vwarning(char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:181
    zephyrproject-rtos#12 0x7ff67f3530eb in warning(char const*, ...) C:/gdb/src/gdb.git/gdbsupport/errors.cc:33
    zephyrproject-rtos#13 0x7ff67baed27f in gdb_bfd_close_warning C:/gdb/src/gdb.git/gdb/gdb_bfd.c:437
    zephyrproject-rtos#14 0x7ff67baed27f in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:646
    zephyrproject-rtos#15 0x7ff67baed27f in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739
    zephyrproject-rtos#16 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82
    zephyrproject-rtos#17 0x7ff68094b6f2 in gdb::ref_ptr<bfd, gdb_bfd_ref_policy>::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91
    zephyrproject-rtos#18 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176

0x1259ea503110 is located 16 bytes inside of 4064-byte region [0x1259ea503100,0x1259ea5040e0)
freed by thread T0 here:
    #0 0x7ff6806b1687 in free C:/gcc/src/gcc-14.2.0/libsanitizer/asan/asan_malloc_win.cpp:90
    zephyrproject-rtos#1 0x7ff67f2ae807 in objalloc_free C:/gdb/src/gdb.git/libiberty/objalloc.c:187
    zephyrproject-rtos#2 0x7ff67d7f56e3 in _bfd_free_cached_info C:/gdb/src/gdb.git/bfd/opncls.c:247
    zephyrproject-rtos#3 0x7ff67d7f2782 in _bfd_delete_bfd C:/gdb/src/gdb.git/bfd/opncls.c:180
    zephyrproject-rtos#4 0x7ff67d7f5df9 in bfd_close_all_done C:/gdb/src/gdb.git/bfd/opncls.c:960
    zephyrproject-rtos#5 0x7ff67d7f62ec in bfd_close C:/gdb/src/gdb.git/bfd/opncls.c:925
    zephyrproject-rtos#6 0x7ff67baecd27 in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:643
    zephyrproject-rtos#7 0x7ff67baecd27 in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739
    zephyrproject-rtos#8 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82
    zephyrproject-rtos#9 0x7ff68094b6f2 in gdb::ref_ptr<bfd, gdb_bfd_ref_policy>::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91
    zephyrproject-rtos#10 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176

It happens because gdb_bfd_close_or_warn uses a bfd-internal name for
the failing-close warning, after the close is finished, and the name
already freed:

static int
gdb_bfd_close_or_warn (struct bfd *abfd)
{
  int ret;
  const char *name = bfd_get_filename (abfd);

  for (asection *sect : gdb_bfd_sections (abfd))
    free_one_bfd_section (sect);

  ret = bfd_close (abfd);

  if (!ret)
    gdb_bfd_close_warning (name,
			   bfd_errmsg (bfd_get_error ()));

  return ret;
}

Fixed by making a copy of the name for the warning.

Approved-By: Andrew Burgess <aburgess@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@stephanosio @EvgeniiDidin @lrgirdwo @dcpleung @MBODAPAT