[Bug dynamic-link/27563] New: _r_debug symbol duplication in the executable breaks the rtdl debug interface state consistency

[Bug dynamic-link/27563] New: _r_debug symbol duplication in the executable breaks the rtdl debug interface state consistency

[ofer.rozentsvaig at intel dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27563

            Bug ID: 27563
           Summary: _r_debug symbol duplication in the executable breaks
                    the rtdl debug interface state consistency
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: ofer.rozentsvaig at intel dot com
  Target Milestone: ---

Hi,

I am working and developing a binary instrumentation tool.
I am using my tool to run an application, and I'm using the r_debug interface
in order to be notified on image load\unloaed events:

I'm tracking the _r_debug->r_brk address, and when reaching the r_brk address,
I check if (_r_debug->r_state == RT_CONSISTENT). If so, I check to see the
changes in the _r_debug->r_map list.

I encountered a problem where my the application's executable also contains a
symbol called _r_debug.
In that case, at some point, main::_r_debug will be used as the active
_r_debug, and the linker::_r_debug will not be used by the linker any more.

Now, it doesn't matter in most cases, as most of the _r_debug fields don't
change. But because I check the "r_state" field, and because I track the
original linker::_r_debug->r_state which is now "stuck" on "RT_ADD", my tool
doesn't operate correctly. In essence, the original linker::_r_debug will never
change its state to RT_CONSISTENT.

I just wanted to know if this is the expected behaviour or a bug.

P.S. The problem becomes more complicated when a shared object loaded by the
executable contains a _r_debug symbol. I will not go over it, as the example
above illustrates my issue quite well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27563] _r_debug symbol duplication in the executable breaks the rtdl debug interface state consistency

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27563

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
Applications and shared libraries should not define any symbols with
underscores, they are reserved names for the implementation.

Please see:
https://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html

If you define a reserved name, the implementation doesn't prevent this, but the
symbol may interpose the implementation symbol (because the executable is first
on the search path).

Does that answer your question?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27563] _r_debug symbol duplication in the executable breaks the rtdl debug interface state consistency

[ofer.rozentsvaig at intel dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27563

--- Comment #2 from ofer <ofer.rozentsvaig at intel dot com> ---
Thank you, Carlos!
It is very helpful.
I got the answer I needed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27563] _r_debug symbol duplication in the executable breaks the rtdl debug interface state consistency

[ofer.rozentsvaig at intel dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27563

ofer <ofer.rozentsvaig at intel dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |NOTABUG
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from ofer <ofer.rozentsvaig at intel dot com> ---
closing

-- 
You are receiving this mail because:
You are on the CC list for the bug.