This is the mail archive of the gdb-testers@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[binutils-gdb] Fix PR gdb/22491: Regression when setting SystemTap probe semaphores


*** TEST RESULTS FOR COMMIT 685de8c2990a04fba5e2954b7ff089a2c641071f ***

Author: Sergio Durigan Junior <sergiodj@redhat.com>
Branch: master
Commit: 685de8c2990a04fba5e2954b7ff089a2c641071f

Fix PR gdb/22491: Regression when setting SystemTap probe semaphores

Pedro has kindly pointed out that
gdb.arch/amd64-stap-optional-prefix.exp was failing after my
C++-ification patches touching the probe interface.  The failure is
kind of cryptic:

 77 break -pstap bar
 78 Breakpoint 3 at 0x40048d
 79 (gdb) PASS: gdb.arch/amd64-stap-optional-prefix.exp: bar: break -pstap bar
 80 continue
 81 Continuing.
 82
 83 Program received signal SIGILL, Illegal instruction.
 84 main () at amd64-stap-optional-prefix.S:26
 85 26              STAP_PROBE1(probe, foo, (%rsp))

It took me a while to figure out where this SIGILL is coming from.
Initially I thought it was something related to writing registers to
the inferior when dealing with probe arguments, but I discarded this
since the arguments were not touching any registers.

In the end, this was a mistake that was introduced during the review
process of the patch.  When setting/clearing a SystemTap probe's
semaphore, the code was using 'm_address' (which refers the probe's
address) instead of 'm_sem_addr' (which refers to the semaphore's
address).  This caused GDB to write a bogus value in the wrong memory
position, which in turn caused the SIGILL.

I am pushing this patch to correct the mistake.

On a side note: I told Pedro that the BuildBot hadn't caught the
failure during my try build, and for a moment there was a suspicion
that the BuildBot might be at fault here.  However, I investigate this
and noticed that I only did one try build, with a patch that was
correctly using 'm_sem_addr' where applicable, and therefore no
failure should have happened indeed.  I probably should have requested
another try build after addressing the review's comments, but they
were mostly basic and I didn't think it was needed.  Oh, well.

2017-11-25  Sergio Durigan Junior  <sergiodj@redhat.com>

	PR gdb/22491
	* stap-probe.c (relocate_address): New function.
	(stap_probe::get_relocated_address): Use 'relocate_address'.
	(stap_probe::set_semaphore): Use 'relocate_address' and pass
	'm_sem_addr'.
	(stap_probe::clear_semaphore): Likewise.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]