Description of problem: Sometimes gdb refuses to write the program counter $pc. When the problem occurs, the first "set $pc = expression" is accepted without complaint but the pc does not change. The second "set $pc = expression" draws a complaint "Attempt to assign to an unmodifiable value" and the pc is not changed. The most-reproducible conditions are when gdb catches a SIGINT (Ctrl-C) while the program is executing a compiled-in breakpoint __asm__("bkpt") which is 0xe1200070. Version-Release number of selected component (if applicable): GNU gdb (GDB) Fedora 8.0.1-33.fc27 How reproducible: Always when a 'bkpt' instruction 0xe1200070 is interrupted via SIGINT (Ctrl-C). Steps to Reproduce: 1. On 32-bit RaspberryPi, execute compiled-in breakpoint __asm__("bkpt") which is 0xe1200070. This is supposed to cause a SIGTRAP, but in kernel-4.14.5-300.fc27.armv7hl it causes: kernel: Unhandled prefetch abort: breakpoint debug exception (0x002) at 0x00010794 2. Try to change the value of pc using "set $pc = expression". gdb will not complain, but a subsequent "x/i $pc" will show that the pc was not changed. 3. Try to change the value of the pc again. This time gdb will complain "Attempt to assign to an unmodifiable value"; the pc does not change. Actual results: $ gdb fraid GNU gdb (GDB) Fedora 8.0.1-33.fc27 <<snip>> Reading symbols from fraid...done. (gdb) run foo Starting program: /home/jreiser/bin/fraid foo Cannot parse expression `.L1199 4@r4'. warning: Probes-based dynamic linker interface failed. Reverting to original interface. 8208 (0x2010) bytes at 0x40000000 ^C Program received signal SIGINT, Interrupt. main (argc=0x2, argv=0xbefff484, envp=0xbefff490) at fraid.c:58 58 __asm__("bkpt"); (gdb) x/i 0x40000000+0x5778-0x4000 0x40001778: sub sp, sp, #4 (gdb) set $pc = $_ ## no complaint (gdb) x/i $pc ## but value did not change => 0x10794 <main+520>: bkpt 0x0000 (gdb) set $pc = 0x40001778 ## complaint Attempt to assign to an unmodifiable value. (gdb) x/i $pc ## was not changed => 0x10794 <main+520>: bkpt 0x0000 (gdb) info proc process 3219 warning: target file /proc/3219/cmdline contained unexpected null characters cmdline = '/home/jreiser/bin/fraid' cwd = '/home/jreiser/github-issue152' exe = '/home/jreiser/bin/fraid' (gdb) shell cat /proc/3219/maps 00010000-00011000 r-xp 00000000 b3:04 269433 /home/jreiser/bin/fraid 00020000-00021000 r--p 00000000 b3:04 269433 /home/jreiser/bin/fraid 00021000-00022000 rw-p 00001000 b3:04 269433 /home/jreiser/bin/fraid 40000000-40003000 rwxs 00000000 b3:04 1038151 /home/jreiser/github-issue152/foo b6e4d000-b6fa4000 r-xp 00000000 b3:04 9080 /usr/lib/libc-2.26.so b6fa4000-b6fb3000 ---p 00157000 b3:04 9080 /usr/lib/libc-2.26.so b6fb3000-b6fb5000 r--p 00156000 b3:04 9080 /usr/lib/libc-2.26.so b6fb5000-b6fb6000 rw-p 00158000 b3:04 9080 /usr/lib/libc-2.26.so b6fb6000-b6fb9000 rw-p 00000000 00:00 0 b6fcb000-b6fee000 r-xp 00000000 b3:04 18105 /usr/lib/ld-2.26.so b6ffb000-b6ffd000 rw-p 00000000 00:00 0 b6ffd000-b6ffe000 r-xp 00000000 00:00 0 [sigpage] b6ffe000-b6fff000 r--p 00023000 b3:04 18105 /usr/lib/ld-2.26.so b6fff000-b7000000 rw-p 00024000 b3:04 18105 /usr/lib/ld-2.26.so befdf000-bf000000 rw-p 00000000 00:00 0 [stack] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] (gdb) Expected results: Additional info: Running on RaspberryPi in 32-bit mode: $ lscpu Architecture: armv7l Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 Model: 4 Model name: ARMv7 Processor rev 4 (v7l) BogoMIPS: 38.40 Flags: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
BTW unless you have verified it is a Fedora GDB specific bug it is better to file such bugs upstream.
(In reply to Jan Kratochvil from comment #1) > ... it is better to file such bugs upstream. And the URL for filing upstream is?
It's https://sourceware.org/bugzilla/enter_bug.cgi?product=gdb As Jan said, please make sure that the issue is present in the upstream version. Thanks!
I request help from Maintainer, please. git tip of upstream gdb does not build. commit 7c1618381fdaa0697a211721ac31844f884797ac (HEAD -> master, origin/master, origin/HEAD) Author: Sergio Durigan Junior <sergiodj> Date: Mon Nov 20 16:34:59 2017 -0500 gcc -c -I. -I. -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -I./../zlib -g -O2 -Wno-error ./syslex_wrap.c ./syslex_wrap.c:25:10: fatal error: syslex.c: No such file or directory #include "syslex.c" ^~~~~~~~~~ compilation terminated. make[2]: *** [Makefile:1375: syslex_wrap.o] Error 1 make[2]: Leaving directory '/home/jreiser/binutils-gdb/binutils' Also, it would have saved me an hour to receive the hint "dnf buildep gdb" because then I would have installed bison and flex in advance instead of "make" discovering that they were missing. Finally, "dnf builddep gdb" says that libipt-devel cannot be found: # dnf builddep gdb enabling updates-source repository enabling fedora-source repository Fedora 27 - Updates Source 3.6 MB/s | 1.6 MB 00:00 Fedora 27 - Source 2.8 MB/s | 6.9 MB 00:02 Last metadata expiration check: 0:00:08 ago on Fri 15 Dec 2017 04:27:56 PM PST. Package gettext-0.19.8.1-11.fc27.armv7hl is already installed, skipping. Package bison-3.0.4-8.fc27.armv7hl is already installed, skipping. Package flex-2.6.1-5.fc27.armv7hl is already installed, skipping. Package texinfo-6.4-6.fc27.armv7hl is already installed, skipping. Package perl-podlators-4.09-394.fc27.noarch is already installed, skipping. Package texinfo-tex-6.4-6.fc27.armv7hl is already installed, skipping. Package rpm-libs-4.14.0-2.fc27.armv7hl is already installed, skipping. No matching package to install: 'libipt-devel' Not all dependencies satisfied Error: Some packages could not be found. I will try again, starting from the very beginning "git clone".
Oh, I'm sorry, I didn't know you needed help with the compilation process. From your description, you're building GDB in an ARM machine. libipt is only available on x86 machines, so it's expected that dnf builddep doesn't find it. Not a problem. You didn't mention the steps you're taking to build GDB, but here's what you need to do: git clone git://sourceware.org/git/binutils-gdb.git mkdir build && cd build ../binutils-gdb/configure --disable-binutils --disable-ld --disable-gold --disable-gas --disable-sim --disable-gprof make Note that you need to disable a few projects from the source tree. Also, I prefer to do out-of-tree builds (i.e., create the "build" directory outside of the source directory), because sometimes in-tree builds are broken. With that you should be able to have a GDB binary built at ./gdb/gdb. To run it without warnings, you need to provide the "--data-directory" option to it. Therefore, from inside the "build" directory, you can: ./gdb/gdb --data-directory ./gdb/data-directory/ <BINARY> That should be enough for you to try to reproduce the failure. Thanks!
(In reply to Sergio Durigan Junior from comment #5) > Oh, I'm sorry, I didn't know you needed help with the compilation process. Following the traditional recipe, beginning at 2000 EST (after having done "dnf install bison flex", and 2 hours before comment #5) I did: git clone git://sourceware.org/git/binutils-gdb.git cd binutils-gdb.git ./configure 2>&1 | tee configure.out make -j4 2>&1 | tee make.out sudo make install Running the just-built-and-installed /usr/local/bin/gdb encounters the original problem. I will file a bug report upstream. Part of the problem seems to be that (gdb) x/i 0x40000000+0x5778-0x4000 0x40001778: sub sp, sp, #4 (gdb) set $pc = $_ ## no complaint (gdb) x/i $pc ## but value did not change => 0x10794 <main+520>: bkpt 0x0000 tries to set the pc to a value that is not associated with the original a.out, but rather with a memory region that was mmap()ed at runtime. I have had several problems with gdb trying to associate all values with the original a.out instead of the actual value of the input expression. In particular, I have found it very hard to use gdb on a "bare metal" user executable: no symbols, no debuginfo, no Elf32_Shdr, just an execve() with "naked" PT_LOAD. That's "too simple" for gdb.
Filed upstream as https://sourceware.org/bugzilla/show_bug.cgi?id=22616
Thanks, I'm adding it as an external bug tracker.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle. Changing version to '30.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.