Red Hat Bugzilla – Full Text Bug Listing
|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:||glibc||Assignee:||Jakub Jelinek <jakub>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-10-23 00:51:52 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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): glibc-2.8-8 How reproducible: always 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.