Bug 192964 - stepping over a function steps into call___do_global_ctors_aux
stepping over a function steps into call___do_global_ctors_aux
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
5
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Alexandre Oliva
:
: 200533 (view as bug list)
Depends On:
Blocks: 218379
  Show dependency treegraph
 
Reported: 2006-05-24 11:16 EDT by Robert Story
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: gdb-6.5-5.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-25 10:36:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch by IBM/Paul Gilliam (599 bytes, patch)
2006-08-13 13:51 EDT, Jan Kratochvil
no flags Details | Diff

  None (edit)
Description Robert Story 2006-05-24 11:16:01 EDT
Description of problem:
stepping over a function in found shared library (eg printf) does not step over
the function, but into call___do_global_ctors_aux.

Version-Release number of selected component (if applicable):
gdb-6.3.0.0-1.122.ppc.rpm
code compiled with gcc-4.1.0-3.ppc.rpm

How reproducible:
Always. Same application build the same way (./configure; make) on fc4 does not
exhibit this behaviour.

Steps to Reproduce:
1. build application
2. run under gdb/ddd
3. step over library function
  
Actual results:
steps into call___do_global_ctors_aux

Expected results:
step over function

Additional info:
This post to the gdb list has good details:
http://sources.redhat.com/ml/gdb/2006-03/msg00224.html

However, note that I'm seeing on a 32bit powerpc machine, with the current fc5
kernel (2.6.16-1.2122_FC5).
Comment 1 Jan Kratochvil 2006-08-13 13:51:50 EDT
Created attachment 134101 [details]
Patch by IBM/Paul Gilliam

This is duplicate of Bug 200533 (OK, 200533 is duplicate of this one), patch
was provided by the courtesy of Paul Gilliam of IBM

2006-05-12  Paul Gilliam  <pgilliam@us.ibm.com>

	* minsyms.c (lookup_minimal_symbol_by_pc_section): Don't ignore
	minimal symbols for solib trampolines just because they're in a
	different section than the PC.

Thanks for your simple reproducibility guide.
Prerelease rpms for FC5-ppc/ppc64 with the patch applied can be found at:
    http://www.jankratochvil.net/priv/pr192964/
Comment 2 Jan Kratochvil 2006-12-19 18:05:16 EST
*** Bug 200533 has been marked as a duplicate of this bug. ***
Comment 3 Jan Kratochvil 2006-12-23 16:40:44 EST
Patch has been updated while it has the same functionality.
Unfortunately it did not help to fix the regression reported as Bug 218379 but
it should have possibly less sideeffects this way and it still should work on ppc.
Testcase has been implemented.
The new patch contains MSYMBOL_SIZE() check as those ppc trampolines have size==0:

+                     /* Don't ignore symbols for solib trampolines.
+                        Limit its sideeffects - only for non-0 sized trampolines.
+                        Red Hat Bug 200533 with its regression Bug 218379.  */
+                     && (MSYMBOL_TYPE (&msymbol[hi]) != mst_solib_trampoline
+                         || MSYMBOL_SIZE (&msymbol[hi]))

Committed to RawHide as:
* Sat Dec 23 2006 Jan Kratochvil <jan.kratochvil@redhat.com> - 6.5-21
- Try to reduce sideeffects of skipping ppc .so libs trampolines (BZ 218379).

The regression of locking up gdb in Bug 218379 should be also hidden by the
upstream minsyms.c patch to be present in RawHide/FC7 gdb-6.6:
http://sourceware.org/ml/gdb-cvs/2006-07/msg00107.html

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