Bug 467343

Summary: Cannot step into shmat() in kdbg even with glibc-debuginfo-2.8-8.x86_64.rpm installed
Product: [Fedora] Fedora Reporter: Philip Ashmore <contact>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: drepper, jakub
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-23 00:51:52 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Philip Ashmore 2008-10-16 18:10:36 EDT
Description of problem:
I'm writing a shared memory app and know that shmat(shmid, 0, 0) picks out an address for me. I want to know what range it picks from.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Write a small "C" program that uses shmat. Let's call it shmem_test
2. kdbg shmem_test
3. Set a breakpoint to the call to shmat().
4. Try to step into it.
Actual results:
kdbg steps over the call

Expected results:
kdbg should open the source file in glibc installed from glibc-debuginfo-2.8-8.x86_64.rpm

Additional info:
I know that shmat() just forwards its parameters to an INLINE_SYSCALL, but still this should work.

Apart from solving this problem, what I'm looking for is a method of querying what address ranges are available to shmat() in the current process.
I expect that this will depend on the size of the shared memory segment.

Also, does anyone know of a pool allocator that can live in a shared memory segment?
Comment 1 Ulrich Drepper 2008-10-23 00:51:52 EDT
This function is written in assembler and has no debug information.  This is no bug.