Bug 1526617 - cannot change program counter $pc
Summary: cannot change program counter $pc
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: gdb
Version: 30
Hardware: armv7l
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Sergio Durigan Junior
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-15 20:53 UTC by John Reiser
Modified: 2019-02-19 17:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Sourceware 22616 None None None 2017-12-16 17:11:54 UTC

Description John Reiser 2017-12-15 20:53:52 UTC
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

Comment 1 Jan Kratochvil 2017-12-15 21:04:35 UTC
BTW unless you have verified it is a Fedora GDB specific bug it is better to file such bugs upstream.

Comment 2 John Reiser 2017-12-15 21:12:37 UTC
(In reply to Jan Kratochvil from comment #1)
> ... it is better to file such bugs upstream.

And the URL for filing upstream is?

Comment 3 Sergio Durigan Junior 2017-12-15 21:20:31 UTC
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!

Comment 4 John Reiser 2017-12-16 00:54:29 UTC
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@redhat.com>
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".

Comment 5 Sergio Durigan Junior 2017-12-16 03:20:54 UTC
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!

Comment 6 John Reiser 2017-12-16 04:17:55 UTC
(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.

Comment 7 John Reiser 2017-12-16 16:54:47 UTC
Filed upstream as https://sourceware.org/bugzilla/show_bug.cgi?id=22616

Comment 8 Sergio Durigan Junior 2017-12-16 17:11:55 UTC
Thanks, I'm adding it as an external bug tracker.

Comment 9 Ben Cotton 2018-11-27 15:43:52 UTC
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.

Comment 10 Ben Cotton 2019-02-19 17:11:51 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle.
Changing version to '30.


Note You need to log in before you can comment on or make changes to this bug.