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:	glibc	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	9	CC:	drepper, jakub
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-10-23 04:51:52 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.