On Wed, 28 Oct 2009, John David Anglin wrote: > On Wed, 28 Oct 2009, Helge Deller wrote: > > > On 10/28/2009 11:43 PM, Helge Deller wrote: > >> On 10/28/2009 11:18 PM, John David Anglin wrote: > >>>>> and whether it follows inb in its .o. From my understanding of things, > >>>>> it shouldn't be necessary to remove the unwind info for unused weak > >>>>> symbols if they aren't garbage collected. A simple testcase would > >>>>> be helpful. > > > > Attached is a testcase (t1.c and t2.c): > > t1.c contains weak function f(). > > t2.c contains non-weak function f(). > > > > hppa-linux-gcc -c t1.c t2.c > > hppa-linux-ld -r -o all.o t1.o t2.o > > > > hppa-linux-readelf -s t1.o gives: > > Symbol table '.symtab' contains 10 entries: > > Num: Value Size Type Bind Vis Ndx Name > > 6: 00000000 28 FUNC GLOBAL DEFAULT 1 a > > 7: 0000001c 32 FUNC WEAK DEFAULT 1 f > > 8: 0000003c 28 FUNC GLOBAL DEFAULT 1 z > > 9: 00000058 80 FUNC GLOBAL DEFAULT 1 main > > > > hppa-linux-readelf -s t2.o gives: > > Symbol table '.symtab' contains 7 entries: > > Num: Value Size Type Bind Vis Ndx Name > > 6: 00000000 32 FUNC GLOBAL DEFAULT 1 f > > > > hppa-linux-readelf -s all.o gives: > > Symbol table '.symtab' contains 11 entries: > > Num: Value Size Type Bind Vis Ndx Name > > 7: 00000000 32 FUNC GLOBAL DEFAULT 3 f > > 8: 0000003c 28 FUNC GLOBAL DEFAULT 1 z > > 9: 00000058 80 FUNC GLOBAL DEFAULT 1 main > > 10: 00000000 28 FUNC GLOBAL DEFAULT 1 a > > > > > > hppa-linux-readelf -u all.o gives: > > Unwind section '.PARISC.unwind' at offset 0xfc contains 5 entries: > > <a>: [0x0-0x30] > > Entry_GR=1 Save_SP Total_frame_size=8 > > <f>: [0x0-0x70] > > Entry_GR=1 Save_SP Total_frame_size=8 > > <z>: [0x3c-0xa8] > > Entry_GR=1 Save_SP Total_frame_size=8 > > <main>: [0x58-0x148] > > Entry_GR=2 Save_SP Save_RP Total_frame_size=8 > > <f>: [0x0-0x38] > > Entry_GR=1 Save_SP Total_frame_size=8 > > > > Function f() is listed twice and with different lengths. > > Sadly in this example f() starts at offset 0. I think if you tweak > > the example, try to see what you get when the start of f() is not zero. > > Looking at all.o with objdump, the code for <f> is still present. > I would say the regions should be: > > <a>: [0x0-0x18] > <f>: [0x1c-0x38] > <z>: [0x3c-0x54] > <main>: [0x58-0xa4] > <f>: [0x0-0x1c] > > There are two .text sections, so the offsets for the second <f> > are relative to the start of this section. > > My compilation probably differs a bit from yours but I see the same > readelf -u output. Suspect readelf is broken. The end values seem > off by a factor 2. readelf -u is definitely broken when used on an object without program headers. However, I think we are creating trouble for ourself by using the function's symbol name for the start offset in the unwind table: Relocation section '.rela.PARISC.unwind' at offset 0x3d8 contains 10 entries: Offset Info Type Sym.Value Sym. Name + Addend 00000000 00000a31 R_PARISC_SEGREL32 00000000 a + 0 00000004 00000131 R_PARISC_SEGREL32 00000000 .text + 18 00000010 00000731 R_PARISC_SEGREL32 00000000 f + 0 00000014 00000131 R_PARISC_SEGREL32 00000000 .text + 38 00000020 00000831 R_PARISC_SEGREL32 0000003c z + 0 00000024 00000131 R_PARISC_SEGREL32 00000000 .text + 54 00000030 00000931 R_PARISC_SEGREL32 00000058 main + 0 00000034 00000131 R_PARISC_SEGREL32 00000000 .text + a4 00000040 00000731 R_PARISC_SEGREL32 00000000 f + 0 00000044 00000231 R_PARISC_SEGREL32 00000000 .text + 1c I think the assembler needs to be changed to use local symbols for the start that will be reduced to section offsets. This should prevent the problem with wrong ranges. However, there may be issues with finding the symbol associated with a range in readelf, etc. Thoughts? Dave -- J. David Anglin dave.anglin@xxxxxxxxxxxxxx National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
