Bug 467343 - Cannot step into shmat() in kdbg even with glibc-debuginfo-2.8-8.x86_64.rpm installed
Summary: Cannot step into shmat() in kdbg even with glibc-debuginfo-2.8-8.x86_64.rpm i...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 9
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-16 22:10 UTC by Philip Ashmore
Modified: 2008-10-23 04:51 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-23 04:51:52 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Philip Ashmore 2008-10-16 22:10:36 UTC
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 04:51:52 UTC
This function is written in assembler and has no debug information.  This is no bug.


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