Bug 2034662 - _r_debug is not constructed for a dyninst mutated executable
Summary: _r_debug is not constructed for a dyninst mutated executable
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: dyninst
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stan Cox
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-12-21 16:09 UTC by Stan Cox
Modified: 2023-03-28 17:36 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-03-28 17:36:15 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
testcase (1.45 KB, application/gzip)
2021-12-21 16:09 UTC, Stan Cox
no flags Details

Description Stan Cox 2021-12-21 16:09:29 UTC
Created attachment 1847202 [details]
testcase

Description of problem:
dyninst uses the _r_debug facility to access the link map of an instrumented executable.  Dyninst can create a new executable containing the instrumentation.  When this is done dyninst sets up its environment with:
 void runDYNINSTBaseInit() __attribute__((constructor));
Part of this process checks _r_debug:
 extern struct r_debug _r_debug;
 DLLEXPORT struct r_debug _r_debug __attribute__ ((weak));

 /* Verify that the r_debug variable is visible */
 void r_debugCheck() { assert(_r_debug.r_map); }
When dyninst creates the instrumented (mutated) executable it changes some sections and does not update _DYNAMIC.  I have a patch to maintain _DYNAMIC but that doesn't solve this as the dyninst runtime library does not have access to the executable's _DYNAMIC.


Version-Release number of selected component (if applicable):
glibc-2.34-9000-26.fc36
possibly related to:
 https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a93d9e03a31ec14405cb3a09aa95413b67067380;hp=885762aa31d75de8b9fea4c0e2e372b582d4c548



Steps to Reproduce:
1. tar -a -x dyn-static.tgz
2. make test

Actual results:
r_debugCheck: Assertion `_r_debug.r_map' failed.

Expected results:
FUNCTION EXECUTED. VALUE = 1
FUNCTION EXECUTED. VALUE = 2
FUNCTION EXECUTED. VALUE = 3
FUNCTION EXECUTED. VALUE = 4
FUNCTION EXECUTED. VALUE = 5

Additional info:

Comment 1 Florian Weimer 2021-12-23 17:42:20 UTC
I implemented copy relocation support for _r_debug in glibc.

I was very disappointed when it did not fix the test case for this bug. But it turns out that it does not involve a copy relocation at all. The issue is that dyninst provides its own definition of _r_debug, which used to interpose glibc's own definition, but does not anymore.

I applied this patch:

diff -ur dyninst-11.0.1.orig/dyninst-11.0.1/dyninstAPI_RT/src/RTlinux.c dyninst-11.0.1/dyninst-11.0.1/dyninstAPI_RT/src/RTlinux.c
--- dyninst-11.0.1.orig/dyninst-11.0.1/dyninstAPI_RT/src/RTlinux.c      2021-06-15 04:23:43.000000000 +0200
+++ dyninst-11.0.1/dyninst-11.0.1/dyninstAPI_RT/src/RTlinux.c   2021-12-23 18:11:27.342260986 +0100
@@ -406,7 +406,6 @@
 #if defined(cap_binary_rewriter)
 
 extern struct r_debug _r_debug;
-DLLEXPORT struct r_debug _r_debug __attribute__ ((weak));
 
 /* Verify that the r_debug variable is visible */
 void r_debugCheck() { assert(_r_debug.r_map); }

And with it, the reproducer passes.

Comment 2 Ben Cotton 2022-02-08 21:19:04 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

Comment 3 Stan Cox 2023-03-28 17:36:15 UTC
fixed in dyninst-12.1.0-4.fc37


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