Bug 268961 - elfutils 129 ignores a local symbol within a global
elfutils 129 ignores a local symbol within a global
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: elfutils (Show other bugs)
8
All All
medium Severity low
: ---
: ---
Assigned To: Denys Vlasenko
Fedora Extras Quality Assurance
bzcl34nup
:
Depends On:
Blocks: 173278
  Show dependency treegraph
 
Reported: 2007-08-30 16:15 EDT by Andrew Cagney
Modified: 2008-11-12 22:36 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-12 22:36:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch for bugs 268961 and 452194 (8.90 KB, patch)
2008-08-13 07:18 EDT, Denys Vlasenko
no flags Details | Diff
Binary file tests/testfile50.o.bz2 (251 bytes, application/x-bzip2)
2008-08-13 07:20 EDT, Denys Vlasenko
no flags Details
Binary file tests/testfile51.o.bz2 (251 bytes, application/x-bzip2)
2008-08-13 07:21 EDT, Denys Vlasenko
no flags Details

  None (edit)
Description Andrew Cagney 2007-08-30 16:15:52 EDT
Consider:

# A global symbol, with size, that contains a nested global and local
# symbols each also with sizes.
GLOBAL(global_outer)
        STORE(REG0, REG0)
        NO_OP
GLOBAL(global_in_global)
        STORE (REG0, REG0)
        NO_OP
        SIZE(global_in_global)
LOCAL(local_in_global)
        STORE (REG0, REG0)                   <----- HERE
        NO_OP 
        SIZE(local_in_global)
.Lglobal_outer:
        STORE (REG0, REG0)
        NO_OP
        SIZE(global_outer)

dwfl_module_addrsym finds global_outer, should it find local_in_global?

I suspect that this isn't stable; consider:

$ nm -p -S frysk-core/frysk/pkglibdir/funit-symbols| grep -e local_in_global -e
global_outer
0804839a 00000003 t local_in_global
08048394 0000000c T global_outer

and:
                  || closest_sym->st_value < sym.st_value
                  || (GELF_ST_BIND (closest_sym->st_info)
                      < GELF_ST_BIND (sym.st_info))))

will select the closer-local or the further global dependant on which is last.
Comment 1 Roland McGrath 2007-09-11 14:54:09 EDT
It prefers a global symbol to a local one by design.  It is stable because ELF
specifies that all local symbols come first in the table.  So, it will always
use the closest of the global symbols.

Always preferring a global symbol is what I said was the plan in the last round
of discussing this.  The rationale was that it's likely to be the function
rather than some label.  But, I don't know of a real-world case like this test
case, i.e. that has a sized local symbol whose range falls inside a sized global
symbol.  (When local symbols are assembly labels, they ordinarily have no size.)
 Perhaps a better rule is the closest sized symbol (regardless of its scope). 
But I would like to see a case of actual code out there that has a sized local
symbol inside a sized global symbol.  AFAIK the compiler never produces that
situation.  The only exception I could think of is when a sized local symbol has
a global alias, and they both have the same st_size.  In that case, I think
preferring the global name is the right choice.

So unless you have a compelling real-world case, I think this is NOTABUG.
Comment 2 Bug Zapper 2008-04-04 09:43:27 EDT
Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.

If this bug still exists in rawhide, please change the version back to
rawhide.
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)

Thanks for your help and we apologize for the interruption.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 3 Denys Vlasenko 2008-07-22 11:24:43 EDT
        nop #0
        .globl global_outer
global_outer:
        nop #1
        .globl global_in_global
global_in_global:
        nop #2
        .size global_in_global, . - global_in_global
local_in_global:
        nop #3
        .size local_in_global, . - local_in_global
        nop #4
.Lsizeless:
        nop #5
        .size global_outer, . - global_outer
        nop #6

# LD_LIBRARY_PATH=libelf:libdw:backends src/addr2line -S -e testcase2.o 0 1 2 3
4 5 6
(.text)+0
??:0
global_outer
??:0
global_in_global   <===== was ist das?
??:0
global_outer+0x2
??:0
global_outer+0x3
??:0
global_outer+0x4
??:0
(.text)+0x6
??:0

It does ignore local_in_global, as Roland intended,
but it picks global_outer and global_in_global inconsistently.
For offset 2, it picked nested global +0, but for offset 3
it selected outer global +2, not nested global +1.

Roland, what should it do in this case? If offset 2 is ok,
are offsets 3,4,5 wrong?
Comment 4 Denys Vlasenko 2008-08-13 07:18:49 EDT
Created attachment 314190 [details]
Proposed patch for bugs 268961 and 452194
Comment 5 Denys Vlasenko 2008-08-13 07:20:25 EDT
Created attachment 314193 [details]
Binary file tests/testfile50.o.bz2
Comment 6 Denys Vlasenko 2008-08-13 07:21:20 EDT
Created attachment 314195 [details]
Binary file tests/testfile51.o.bz2
Comment 7 Denys Vlasenko 2008-08-13 09:45:31 EDT
> (.text)+0
> ??:0
> global_outer
> ??:0
> global_in_global   <===== was ist das?
> ??:0

Just for the record: this is ok. global_in_global is a one-byte sized "routine", and thus it is selected as the smallest sized routing which contains this address.
Comment 8 Fedora Update System 2008-08-28 15:53:51 EDT
elfutils-0.137-2.fc8 has been submitted as an update for Fedora 8.
http://admin.fedoraproject.org/updates/elfutils-0.137-2.fc8
Comment 9 Fedora Update System 2008-08-28 15:56:05 EDT
elfutils-0.137-2.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/elfutils-0.137-2.fc9
Comment 10 Fedora Update System 2008-09-10 02:37:11 EDT
elfutils-0.137-2.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update elfutils'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-7460
Comment 11 Fedora Update System 2008-09-10 03:02:40 EDT
elfutils-0.137-2.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update elfutils'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-7464
Comment 12 Fedora Update System 2008-10-03 18:29:33 EDT
elfutils-0.137-3.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update elfutils'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-7464
Comment 13 Fedora Update System 2008-10-03 18:34:57 EDT
elfutils-0.137-3.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update elfutils'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-7460
Comment 14 Fedora Update System 2008-11-12 22:35:52 EST
elfutils-0.137-3.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Fedora Update System 2008-11-12 22:36:18 EST
elfutils-0.137-3.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

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