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.
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.
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.
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?
Created attachment 314190 [details] Proposed patch for bugs 268961 and 452194
Created attachment 314193 [details] Binary file tests/testfile50.o.bz2
Created attachment 314195 [details] Binary file tests/testfile51.o.bz2
> (.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.
elfutils-0.137-2.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/elfutils-0.137-2.fc8
elfutils-0.137-2.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/elfutils-0.137-2.fc9
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
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
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
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
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.
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.