From: Aditya Kamath1 <Aditya.Kamath1@ibm.com>
To: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
"tom@tromey.com" <tom@tromey.com>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>,
"simon.marchi@efficios.com" <simon.marchi@efficios.com>
Subject: Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning
Date: Fri, 21 Apr 2023 13:00:46 +0000 [thread overview]
Message-ID: <CH2PR15MB35442EE01CC59A685984437FD6609@CH2PR15MB3544.namprd15.prod.outlook.com> (raw)
In-Reply-To: <6dba16478c04d83780e4996236ba4fad4d7a5395.camel@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 37230 bytes --]
Hi Ulrich, Tom and community,
So here is my further understanding to this.
>Instead of simply disabling generation of those psymtab entries,
>I think we should first understand why those values end up wrong.
>Is this already a problem in the underlying XCOFF file debug info,
>or is this just read in incorrectly by GDB/BFD at some point?
>Can you debug a bit more exactly where the wrong values come from?
>Is there some AIX tool you can use to look at the XCOFF debug info
>directly to compare with what GDB is reading?
Consider the example
1: #include <stdio.h>
2: int global_variable = 2;
3: int main(){
4: int local_variable = 1;
5: printf ("Simple print statement \n");
6: printf ("Hello Bengaluru \n");
7: return 0;
8:}
For this code there are 345 symbols I see using the dump -tov ~/gdb_tests/simple_test.. I have pasted them below this email…
All of them are getting into the tables via xcoff_initial_scan code. Their entries are also same as the object dump.
So here is the thing, there are 4 values for which the psymtab entries are created. Their addresses are 0, 1a0, 0 and 8.
In the object dump outputs I see they are like this..
[235] m 0x00000000 debug 0 gsym __new_exitfn_called:G13=14=@s64;r14;0;01777777777777777777777;
[236] m 0x00000008 debug 0 gsym __exit_funcs:G4
[188] m 0x000001a0 debug 0 fun __internal_atexit:F8=r8;-2147483648;2147483647;
[177] m 0x00000000 debug 0 fun __new_exitfn:F1=*2=xsexit_function:
It looks like these are global symbols and functions. Hence they satisfy the case G in the xcoffread.c file and psymtab entries are created.
Kindly have a look at the disassemble output of this code,
(gdb) disassemble
Dump of assembler code for function main:
0x10000518 <+0>: mflr r0
0x1000051c <+4>: stw r0,8(r1)
0x10000520 <+8>: stw r31,-4(r1)
0x10000524 <+12>: stwu r1,-96(r1)
0x10000528 <+16>: mr r31,r1
0x1000052c <+20>: li r9,1
0x10000530 <+24>: stw r9,56(r31)
0x10000534 <+28>: lwz r3,64(r2)
0x10000538 <+32>: warning: (Internal error: pc 0x100005a8 in read in psymtab, but not in symtab.)
bl 0x100005a8 <puts>
0x1000053c <+36>: lwz r2,20(r1)
=> 0x10000540 <+40>: lwz r3,72(r2)
0x10000544 <+44>: warning: (Internal error: pc 0x100005a8 in read in psymtab, but not in symtab.)
bl 0x100005a8 <puts>
0x10000548 <+48>: lwz r2,20(r1)
0x1000054c <+52>: li r9,0
0x10000550 <+56>: mr r3,r9
0x10000554 <+60>: addi r1,r31,96
0x10000558 <+64>: lwz r0,8(r1)
0x1000055c <+68>: mtlr r0
0x10000560 <+72>: lwz r31,-4(r1)
0x10000564 <+76>: blr
0x10000568 <+80>: .long 0x0
0x1000056c <+84>: .long 0x2061
0x10000570 <+88>: lwz r0,1(r1)
0x10000574 <+92>: .long 0x50
0x10000578 <+96>: .long 0x46d61
0x1000057c <+100>: xori r14,r11,7936
End of assembler dump.
(gdb)
When we are at line number 4 of the C code and press a next, GDB is searching for the next pc which is 0x100005a8, nothing but in search of printf ().This is done in the function find_pc_sect_line () in symtab.c.
Here pc parameter in the function is 0x100005a8. GDB here figures out this is a shared library trampoline. In gdb terms mst_solib_trampoline.
So it goes in search of find_pc_line (mfunsym.value_address (), 0); Where mfunsym.value_address is d03b0160 which is range of the libc shared library and 0 indicates to not raise a warning.
info sharedlibrary output
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0xd05bb240 0xd05bb9a1 Yes (*) /usr/lib/libcrypt.a(shr.o)
0xd0100e00 0xd0575123 Yes (*) /usr/lib/libc.a(shr.o)
(*): Shared library is missing debugging information.
(gdb)
Now, GDB searches for pc d03b0160 again in function find_pc_sect_line () in symtab.c…
This address is not there in object dump output, not there in symbol table and not there in psymbol table as well.
Hence now it goes into “ cust = find_pc_sect_compunit_symtab (pc, section); “ with this pc. This is where the psymtab journey and the mess starts. This function is again in the symtab.c file. It searches throughout the symbol table and does not find the address d03b0160.
Now it gets into this code
/* Not found in symtabs, search the "quick" symtabs (e.g. psymtabs). */
for (objfile *objf : current_program_space->objfiles ())
{
struct compunit_symtab *result
= objf->find_pc_sect_compunit_symtab (msymbol, pc, section, 1);
if (result != NULL)
return result;
}
We can see objf->find_pc_sect_compunit_symtab (msymbol, pc, section, 1);, the warnings are turned on now. Through the find_pc_sect_compunit_symtab under the psymtab namespace it goes in search of the best_pc.
The route it takes is psymbol_functions::find_pc_sect_compunit_symtab () -> psymbol_functions::find_pc_sect_psymtab () -> find_pc_sect_psymtab_closer () -> p = find_pc_sect_psymbol (objfile, tpst, pc, section);
So all this is done to find the best nearest pc possible..
Along these lines in find_pc_sect_symbol ()
for (partial_symbol *p : psymtab->global_psymbols)
{
if (p->domain == VAR_DOMAIN
&& p->aclass == LOC_BLOCK
&& pc >= p->address (objfile)
&& (p->address (objfile) > best_pc
|| (psymtab->text_low (objfile) == 0
&& best_pc == 0 && p->address (objfile) == 0)))
{
if (section != NULL) /* Match on a specific section. */
{
if (!matching_obj_sections (p->obj_section (objfile),
section))
continue;
}
best_pc = p->address (objfile);
best = p;
}
}
Over here we know that address 1a0 will be closest to mfunsym.value_address or printf () address d03b0160. Hence this psymtab entry is returned. Although this is far from being close but still turns out to be the best. This makes me confused why we are looking for the best nearest PC here. Shouldn’t this have some limit to the difference in pc’s of what we are looking for??
This is where I feel we need to change our logic.
After this in the psymbol_functions::find_pc_sect_compunit_symtab () since it returned that 1a0’s psymtab entry, the below code does the rest. And AIX GDB is flooded with the warnings.
struct partial_symtab *ps = find_pc_sect_psymtab (objfile,
pc, section,
msymbol);
if (ps != NULL)
{
if (warn_if_readin && ps->readin_p (objfile))
/* Might want to error() here (in case symtab is corrupt and
will cause a core dump), but maybe we can successfully
continue, so let's not. */
warning (_("\
(Internal error: pc %s in read in psymtab, but not in symtab.)\n"),
paddress (objfile->arch (), pc));
psymtab_to_symtab (objfile, ps);
return ps->get_compunit_symtab (objfile);
}
So concluding my explain nation, there are two things.
One is this psymtab entries, we need to limit the difference of pc that can be used as best_pc.. This can be one entry point to take control and add a symbol table for AIX for this printf (). Such that if the limit is too much this might indicate the need for an external shared library symbol and add the symbol entry. I see in dwarf2/read.c there is some code doing the shared library entries if I understood it correctly. But I do not know if this can be the correct way. But I got my previous patch wrong. That I can say for sure. Removing the psymtab entries may not be correct and these entries are what is there in the object dump.
Second thing, we can think is some kind of lazy loading where the moment we detect a shared library trampoline to be executed or will be the PC we can create the symbol table entry for the shared library functions, so that before GDB jumps into of find_pc_line (mfunsym.value_address (), 0), we can add the symbol table entry.
I have not succeeded so far in my attempt to fix this though I learnt different things about symbols and symbol table. I have given the explanation to what I understood and where can be the points we can make changes.
Kindly guide me, so that we can fix this issue for GDB and AIX. I want to know what can we do next from here, given we know what is going on and the root cause and place of problem for the same.
Awaiting a reply.
Have a nice day ahead.
Thanks and regards,
Aditya.
------------------------------------------------------
Object dump output-----
dump -tov ~/gdb_tests/simple_test
/home/aditya/gdb_tests/simple_test:
***Object Module Header***
# Sections Symbol Ptr # Symbols Opt Hdr Len Flags
10 0x00002078 345 72 0x1002
Flags=( EXEC DYNLOAD DEP_SYSTEM )
Timestamp = "Apr 21 01:07:51 2023"
Magic = 0x1df (32-bit XCOFF)
***Optional Header***
Tsize Dsize Bsize Tstart Dstart
0x00000b6d 0x000001d7 0x00000214 0x10000290 0x20000dfd
SNloader SNentry SNtext SNtoc SNdata
0x0004 0x0002 0x0001 0x0002 0x0002
TXTalign DATAalign TOC vstamp entry
0x0005 0x0004 0x20000f5c 0x0001 0x20000f24
maxSTACK maxDATA SNbss magic modtype
0x00000000 0x00000000 0x0003 0x010b 1L
***Symbol Table Information***
[Index] m Value Scn Aux Sclass Type Name
[Index] a0 Fname
[Index] a1 Tagndx Lnno Size Lnoptr Endndx
[Index] a2 Tagndx Fsiz Lnoptr Endndx
[Index] a3 Tagndx Lnno Size Dimensions
[Index] a4 CSlen PARMhsh SNhash SMtype SMclass Stab SNstab
[Index] a5 SECTlen #RELent #LINnums
[0] m 0x00000000 undef 1 extern errno
[1] a4 0x00000000 0 0 ER RW 0 0
[2] m 0x00000000 undef 1 extern calloc
[3] a4 0x00000000 0 0 ER DS 0 0
[4] m 0x00000000 undef 1 extern exit
[5] a4 0x00000000 0 0 ER DS 0 0
[6] m 0x00000000 undef 1 extern __assert
[7] a4 0x00000000 0 0 ER DS 0 0
[8] m 0x00000000 undef 1 extern puts
[9] a4 0x00000000 0 0 ER DS 0 0
[10] m 0x00000000 undef 1 extern __strtollmax
[11] a4 0x00000000 0 0 ER DS 0 0
[12] m 0x00000000 undef 1 extern __mod_init
[13] a4 0x00000000 0 0 ER DS 0 0
[14] m 0x00000000 undef 1 extern __crt0v
[15] a4 0x00000000 0 0 ER RW 0 0
[16] m 0x00000000 undef 1 extern __malloc_user_defined_name
[17] a4 0x00000000 0 0 ER RW 0 0
[18] m 0x20000f5c .data 1 unamex TOC
[19] a4 0x00000000 0 0 SD TC0 0 0
[20] m 0x20000f84 .data 1 unamex __crt0v
[21] a4 0x00000004 0 0 SD TC 0 0
[22] m 0x20000f88 .data 1 unamex __mod_init
[23] a4 0x00000004 0 0 SD TC 0 0
[24] m 0x20000f8c .data 1 unamex crt0_data
[25] a4 0x00000004 0 0 SD TC 0 0
[26] m 0x20000f90 .data 1 unamex __malloc_user_defined_name
[27] a4 0x00000004 0 0 SD TC 0 0
[28] m 0x20000f94 .data 1 unamex errno
[29] a4 0x00000004 0 0 SD TC 0 0
[30] m 0x20000f98 .data 1 unamex __strtollmax
[31] a4 0x00000004 0 0 SD TC 0 0
[32] m 0x20000f9c .data 1 unamex LC..0
[33] a4 0x00000004 0 0 SD TC 0 0
[34] m 0x20000fa0 .data 1 unamex puts
[35] a4 0x00000004 0 0 SD TC 0 0
[36] m 0x20000fa4 .data 1 unamex LC..2
[37] a4 0x00000004 0 0 SD TC 0 0
[38] m 0x20000fa8 .data 1 unamex exit
[39] a4 0x00000004 0 0 SD TC 0 0
[40] m 0x20000fac .data 1 unamex __dso_handle
[41] a4 0x00000004 0 0 SD TC 0 0
[42] m 0x20000fb0 .data 1 unamex __exit_funcs
[43] a4 0x00000004 0 0 SD TC 0 0
[44] m 0x20000fb4 .data 1 unamex LANCHOR..0
[45] a4 0x00000004 0 0 SD TC 0 0
[46] m 0x20000fb8 .data 1 unamex calloc
[47] a4 0x00000004 0 0 SD TC 0 0
[48] m 0x20000fbc .data 1 unamex LANCHOR..1
[49] a4 0x00000004 0 0 SD TC 0 0
[50] m 0x20000fc0 .data 1 unamex __assert
[51] a4 0x00000004 0 0 SD TC 0 0
[52] m 0x20000fc4 .data 1 unamex __new_exitfn_called
[53] a4 0x00000004 0 0 SD TC 0 0
[54] m 0x20000fc8 .data 1 unamex count
[55] a4 0x00000004 0 0 SD TC 0 0
[56] m 0x20000fcc .data 1 unamex dtors.0
[57] a4 0x00000004 0 0 SD TC 0 0
[58] m 0x20000fd0 .data 1 unamex dtors.0.P4
[59] a4 0x00000004 0 0 SD TC 0 0
[60] m 0x0000003d debug 0 FILE FRONT:COM
[61] m 0x00000052 debug 0 FILE ASM:COM crt0main.s
[62] m 0x10000290 .text 1 unamex .__start
[63] a4 0x000000a5 0 0 SD PR 0 0
[64] m 0x10000290 .text 1 extern .__start
[65] a4 0x0000003e 0 0 LD PR 0 0
[66] m 0x20000f24 .data 1 extern __start
[67] a4 0x00000008 0 0 SD DS 0 0
[68] m 0x20000e00 .data 1 unamex crt0_data
[69] a4 0x0000002c 0 0 SD RW 0 0
[70] m 0x20000f60 .data 1 extern p_xargc
[71] a4 0x00000004 0 0 CM TD 0 0
[72] m 0x20000f78 .data 1 extern p_xargv
[73] a4 0x00000004 0 0 CM TD 0 0
[74] m 0x20000f7c .data 1 extern p_xrcfg
[75] a4 0x00000004 0 0 CM TD 0 0
[76] m 0x20000f80 .data 1 extern p_xrc
[77] a4 0x00000004 0 0 CM TD 0 0
[78] m 0x20000f5c .data 1 extern _malloc_user_defined_name
[79] a4 0x00000004 0 0 CM TD 0 0
[80] m 0x200011e4 .bss 1 extern __C_runtime_pstartup
[81] a4 0x00000004 0 0 CM RW 0 0
[82] m 0x0000006a debug 3 FILE C:COM .file
[83] a0 ../../../../../../../src/bos/usr/ccs/lib/libc/__threads_init.c
[84] a0 Tue May 7 10:49:34 2019
[85] a0 IBM XL C for AIX, Version 13.1.0.2
[86] m 0x10000340 .text 1 unamex **No Symbol**
[87] a4 0x00000160 0 0 SD PR 0 0
[88] m 0x10000340 .text 1 extern .__threads_init
[89] a4 0x00000056 0 0 LD PR 0 0
[90] m 0x10000380 .text 1 unamex .__threads_init@AF2_1<mailto:.__threads_init@AF2_1>
[91] a4 0x00000056 0 0 LD PR 0 0
[92] m 0x20000e30 .data 1 unamex _$STATIC
[93] a4 0x00000059 0 0 SD RW 0 0
[94] m 0x20000f2c .data 1 extern __threads_init
[95] a4 0x0000000c 0 0 SD DS 0 0
[96] m 0x20000f64 .data 1 extern __pth_init_routine
[97] a4 0x00000004 0 0 CM TD 0 0
[98] m 0x20000f68 .data 1 extern _bsd_init_routine
[99] a4 0x00000004 0 0 CM TD 0 0
[100] m 0x20000f6c .data 1 extern _xti_tli_init_routine
[101] a4 0x00000004 0 0 CM TD 0 0
[102] m 0x20000f70 .data 1 extern _nsl_init_routine
[103] a4 0x00000004 0 0 CM TD 0 0
[104] m 0x20000f74 .data 1 extern __dce_compat_init_routine
[105] a4 0x00000004 0 0 CM TD 0 0
[106] m 0x0000007d debug 0 FILE C:COM /tmp//ccxFwDye.cdtor.c
[107] m 0x10000ad4 .text 1 unamex .text
[108] a4 0x00000124 0 0 SD PR 0 0
[109] m 0x10000ad4 .text 1 extern ._GLOBAL__FI_simple_test
[110] a4 0x0000006b 0 0 LD PR 0 0
[111] m 0x10000b30 .text 1 extern ._GLOBAL__FD_simple_test
[112] a4 0x0000006b 0 0 LD PR 0 0
[113] m 0x20000f44 .data 1 unamex _GLOBAL__FI_simple_test
[114] a4 0x0000000c 0 0 SD DS 0 0
[115] m 0x20000f44 .data 1 extern _GLOBAL__FI_simple_test
[116] a4 0x00000071 0 0 LD DS 0 0
[117] m 0x20000f50 .data 1 unamex _GLOBAL__FD_simple_test
[118] a4 0x0000000c 0 0 SD DS 0 0
[119] m 0x20000f50 .data 1 extern _GLOBAL__FD_simple_test
[120] a4 0x00000075 0 0 LD DS 0 0
[121] m 0x20000eb0 .data 1 unamex _ccxFwDyecdtor.rw_
[122] a4 0x00000004 0 0 SD RW 0 0
[123] m 0x200011e0 .bss 1 unamex _ccxFwDyecdtor.bss_
[124] a4 0x00000004 0 0 CM BS 0 0
[125] m 0x0000008e debug 0 FILE C:COM ../../../gcc-10.3.0/libgcc/config/rs6000/crtcxa.c
[126] m 0x1000062c .text 1 unamex .text
[127] a4 0x00000000 0 0 SD PR 0 0
[128] m 0x100005f8 .text 1 unamex ..text.exit
[129] a4 0x00000034 0 0 SD PR 0 0
[130] m 0x100005f8 .text 1 extern .__init_aix_libgcc_cxa_atexit
[131] a4 0x00000080 0 0 LD PR 0 0
[132] m 0x10000628 .text 1 extern ._GLOBAL__D_65535_0___dso_handle
[133] a4 0x00000080 0 0 LD PR 0 0
[134] m 0x20000e90 .data 1 unamex .data
[135] a4 0x00000008 0 0 SD RW 0 0
[136] m 0x20000e90 .data 1 extern __dso_handle
[137] a4 0x00000086 0 0 LD RW 0 0
[138] m 0x20000f38 .data 1 unamex _GLOBAL__D_65535_0___dso_handle
[139] a4 0x0000000c 0 0 SD DS 0 0
[140] m 0x20000f38 .data 1 extern _GLOBAL__D_65535_0___dso_handle
[141] a4 0x0000008a 0 0 LD DS 0 0
[142] m 0x000000a3 debug 0 FILE C:COM /home/aditya/gdb_tests/simple_test.c
[143] m 0x00000000 .dwline 1 dwarf .dwline
[144] a5 0x00000118 0x0000
[145] m 0x00000000 .dwinfo 1 dwarf .dwinfo
[146] a5 0x00000223 0x0000
[147] m 0x00000000 .dwabrev 1 dwarf .dwabrev
[148] a5 0x000000b2 0x0000
[149] m 0x00000000 .dwarnge 1 dwarf .dwarnge
[150] a5 0x00000020 0x0000
[151] m 0x00000000 .dwloc 1 dwarf .dwloc
[152] a5 0x00000074 0x0000
[153] m 0x100004a0 .text 1 unamex .text
[154] a4 0x000000e0 0 0 SD PR 0 0
[155] m 0x100004a0 .text 2 unamex .strtoimax
[156] a2 0 224 7658 135
[157] a4 0x00000099 0 0 LD PR 0 0
[158] m 0x10000518 .text 2 extern .main
[159] a2 0 224 7664 135
[160] a4 0x00000099 0 0 LD PR 0 0
[161] m 0x10000c00 .text 1 unamex _simpletest.rop_
[162] a4 0x00000029 0 0 SD RO 0 0
[163] m 0x000000fb debug 0 FILE C:PPC ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[164] m 0x00001f76 debug 0 bincl ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[165] m 0x00001f76 debug 0 eincl ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[166] m 0x00001f82 debug 0 bincl ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[167] m 0x00001f82 debug 0 eincl ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[168] m 0x00001f8e debug 0 bincl ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[169] m 0x00001fbe debug 0 eincl ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[170] m 0x00001fca debug 0 bincl ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[171] m 0x00001fca debug 0 eincl ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[172] m 0x100007a8 .text 1 unamex .text
[173] a4 0x000002dc 0 0 SD PR 0 0
[174] m 0x100007a8 .text 2 extern .__new_exitfn
[175] a2 0 416 7670 185
[176] a4 0x000000ac 0 0 LD PR 0 0
[177] m 0x00000000 debug 0 fun __new_exitfn:F1=*2=xsexit_function:
[178] m 0x100007a8 .text 1 fcn .bf
[179] a1 0 75 0 0 0
[180] m 0x0000001f debug 0 rpsym listp:R3=*4=*5=xsexit_function_list:
[181] m 0x00000003 debug 0 rsym r:r1
[182] m 0x00000009 debug 0 rsym i:r6=7=r7;0;037777777777;
[183] m 0x10000924 .text 1 fcn .ef
[184] a1 0 131 0 0 0
[185] m 0x10000948 .text 2 extern .__internal_atexit
[186] a2 0 156 7952 197
[187] a4 0x000000ac 0 0 LD PR 0 0
[188] m 0x000001a0 debug 0 fun __internal_atexit:F8=r8;-2147483648;2147483647;
[189] m 0x10000948 .text 1 fcn .bf
[190] a1 0 40 0 0 0
[191] m 0x0000001d debug 0 rpsym func:R9=*10=f11=11
[192] m 0x0000001e debug 0 rpsym arg:R12=*11
[193] m 0x0000001f debug 0 rpsym d:R12
[194] m 0x00000006 debug 0 rpsym listp:R3
[195] m 0x100009bc .text 1 fcn .ef
[196] a1 0 55 0 0 0
[197] m 0x100009e8 .text 2 extern .__cxa_atexit
[198] a2 0 156 8042 235
[199] a4 0x000000ac 0 0 LD PR 0 0
[200] m 0x100009e8 .text 1 fcn .bf
[201] a1 0 63 0 0 0
[202] m 0x0000001d debug 0 rpsym func:R9
[203] m 0x0000001e debug 0 rpsym arg:R12
[204] m 0x0000001f debug 0 rpsym d:R12
[205] m 0x100009f0 .text 1 block .bb
[206] a1 0 1 0 0 53
[207] m 0x100009f4 .text 1 block .eb
[208] a1 0 63 0 0 0
[209] m 0x10000a08 .text 1 block .bb
[210] a1 0 1 0 0 61
[211] m 0x10000a08 .text 1 block .bb
[212] a1 0 1 0 0 59
[213] m 0x10000a0c .text 1 block .eb
[214] a1 0 63 0 0 0
[215] m 0x10000a0c .text 1 block .eb
[216] a1 0 63 0 0 0
[217] m 0x10000a14 .text 1 block .bb
[218] a1 0 1 0 0 69
[219] m 0x10000a14 .text 1 block .bb
[220] a1 0 1 0 0 67
[221] m 0x10000a3c .text 1 block .eb
[222] a1 0 63 0 0 0
[223] m 0x10000a3c .text 1 block .eb
[224] a1 0 63 0 0 0
[225] m 0x10000a58 .text 1 block .bb
[226] a1 0 3 0 0 77
[227] m 0x10000a58 .text 1 block .bb
[228] a1 0 3 0 0 75
[229] m 0x10000a5c .text 1 block .eb
[230] a1 0 65 0 0 0
[231] m 0x10000a5c .text 1 block .eb
[232] a1 0 65 0 0 0
[233] m 0x10000a60 .text 1 fcn .ef
[234] a1 0 65 0 0 0
[235] m 0x00000000 debug 0 gsym __new_exitfn_called:G13=14=@s64;r14;0;01777777777777777777777;
[236] m 0x00000008 debug 0 gsym __exit_funcs:G4
[237] m 0x10000dc0 .text 1 unamex _cxaatexit.rop_
[238] a4 0x0000003d 0 0 SD RO 0 0
[239] m 0x10000cb0 .text 1 unamex _cxaatexit.ro_
[240] a4 0x00000104 0 0 SD RO 0 0
[241] m 0x10000cb0 .text 1 extern _GLOBAL__F___internal_atexit
[242] a4 0x000000ef 0 0 LD RO 0 0
[243] m 0x20000ea0 .data 1 unamex .data
[244] a4 0x00000010 0 0 SD RW 0 0
[245] m 0x20000ea0 .data 1 extern __new_exitfn_called
[246] a4 0x000000f3 0 0 LD RW 0 0
[247] m 0x20000ea8 .data 1 extern __exit_funcs
[248] a4 0x000000f3 0 0 LD RW 0 0
[249] m 0x20000fd8 .bss 1 unamex _cxaatexit.bss_3_
[250] a4 0x00000208 0 0 CM BS 0 0
[251] m 0x00000140 debug 0 FILE C:PPC ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_finalize.c
[252] m 0x00001fe2 debug 0 bincl ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_finalize.c
[253] m 0x00001fe2 debug 0 eincl ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_finalize.c
[254] m 0x00002048 debug 0 bincl ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_finalize.c
[255] m 0x00002048 debug 0 eincl ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_finalize.c
[256] m 0x1000062c .text 1 unamex .text
[257] a4 0x0000017c 0 0 SD PR 0 0
[258] m 0x1000062c .text 2 extern .__cxa_finalize
[259] a2 0 380 8150 316
[260] a4 0x00000100 0 0 LD PR 0 0
[261] m 0x1000062c .text 1 fcn .bf
[262] a1 0 44 0 0 0
[263] m 0x0000001b debug 0 rpsym d:R1=*2=2
[264] m 0x0000001a debug 0 rsym funcs:r3=*4=xsexit_function_list:
[265] m 0x0000001f debug 0 rsym f:r5=*6=xsexit_function:
[266] m 0x10000660 .text 1 block .bb
[267] a1 0 1 0 0 34
[268] m 0x00000009 debug 0 rsym cxafn:r7=*8=f2
[269] m 0x00000003 debug 0 rsym cxaarg:r1
[270] m 0x10000660 .text 1 block .bb
[271] a1 0 1 0 0 32
[272] m 0x10000660 .text 1 block .bb
[273] a1 0 1 0 0 30
[274] m 0x10000664 .text 1 block .eb
[275] a1 0 44 0 0 0
[276] m 0x10000664 .text 1 block .eb
[277] a1 0 44 0 0 0
[278] m 0x10000664 .text 1 block .eb
[279] a1 0 44 0 0 0
[280] m 0x10000688 .text 1 block .bb
[281] a1 0 5 0 0 45
[282] m 0x0000001f debug 0 rsym f:r5
[283] m 0x100006ac .text 1 block .bb
[284] a1 0 9 0 0 43
[285] m 0x00000009 debug 0 rsym cxafn:r7
[286] m 0x00000003 debug 0 rsym cxaarg:r1
[287] m 0x100006bc .text 1 block .eb
[288] a1 0 14 0 0 0
[289] m 0x100006c8 .text 1 block .eb
[290] a1 0 14 0 0 0
[291] m 0x1000071c .text 1 block .bb
[292] a1 0 42 0 0 68
[293] m 0x0000001f debug 0 rsym f:r5
[294] m 0x1000071c .text 1 block .bb
[295] a1 0 42 0 0 66
[296] m 0x00000009 debug 0 rsym cxafn:r7
[297] m 0x00000003 debug 0 rsym cxaarg:r1
[298] m 0x10000724 .text 1 block .bb
[299] a1 0 17 0 0 60
[300] m 0x10000724 .text 1 block .bb
[301] a1 0 17 0 0 58
[302] m 0x1000073c .text 1 block .eb
[303] a1 0 60 0 0 0
[304] m 0x1000073c .text 1 block .eb
[305] a1 0 60 0 0 0
[306] m 0x10000740 .text 1 block .bb
[307] a1 0 16 0 0 64
[308] m 0x10000784 .text 1 block .eb
[309] a1 0 30 0 0 0
[310] m 0x10000784 .text 1 block .eb
[311] a1 0 30 0 0 0
[312] m 0x10000784 .text 1 block .eb
[313] a1 0 30 0 0 0
[314] m 0x10000784 .text 1 fcn .ef
[315] a1 0 85 0 0 0
[316] m 0x10000c30 .text 1 unamex _cxafinalize.ro_
[317] a4 0x00000080 0 0 SD RO 0 0
[318] m 0x10000c30 .text 1 extern _GLOBAL__F___cxa_finalize
[319] a4 0x0000013c 0 0 LD RO 0 0
[320] m 0x00000145 debug 0 FILE ASM:COM glink.s
[321] m 0x100005d0 .text 1 unamex .exit
[322] a4 0x00000028 0 0 SD GL 0 0
[323] m 0x100005d0 .text 1 extern .exit
[324] a4 0x00000141 0 0 LD GL 0 0
[325] m 0x0000014a debug 0 FILE ASM:COM glink.s
[326] m 0x10000580 .text 1 unamex .__strtollmax
[327] a4 0x00000028 0 0 SD GL 0 0
[328] m 0x10000580 .text 1 extern .__strtollmax
[329] a4 0x00000146 0 0 LD GL 0 0
[330] m 0x0000014f debug 0 FILE ASM:COM glink.s
[331] m 0x100005a8 .text 1 unamex .puts
[332] a4 0x00000028 0 0 SD GL 0 0
[333] m 0x100005a8 .text 1 extern .puts
[334] a4 0x0000014b 0 0 LD GL 0 0
[335] m 0x00000154 debug 0 FILE ASM:COM glink.s
[336] m 0x10000a84 .text 1 unamex .calloc
[337] a4 0x00000028 0 0 SD GL 0 0
[338] m 0x10000a84 .text 1 extern .calloc
[339] a4 0x00000150 0 0 LD GL 0 0
[340] m 0xffffffff debug 0 FILE ASM:COM glink.s
[341] m 0x10000aac .text 1 unamex .__assert
[342] a4 0x00000028 0 0 SD GL 0 0
[343] m 0x10000aac .text 1 extern .__assert
[344] a4 0x00000155 0 0 LD GL 0 0
From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Date: Tuesday, 18 April 2023 at 3:42 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>, Aditya Kamath1 <Aditya.Kamath1@ibm.com>, tom@tromey.com <tom@tromey.com>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>, simon.marchi@efficios.com <simon.marchi@efficios.com>
Subject: Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning
Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:
>What I realised is the address that is being passed as GLOBALS
>looks bogus in the xcoffread.c file. I did not find it in object
>dump. The core address for which the psymtab entries made
>are 0 ,1a0, 0 and 8 for the below code.. These are not correct
>core addresses at all. I was surprised as to where it came from
>at first place.
>Seeing the comments around the same place in xcoffread.c file at
>the hunk lines of this patch , it looks like someone already knew
>these addresses are incorrect in the past. And even in my investigation
>I figured out that these psymbols are incorrect. Hence when function
>shared library addresses are looked up in psymtab GDB finds the
>nearest best false pysmtab symbol and returns it. Which it should not do.
Instead of simply disabling generation of those psymtab entries,
I think we should first understand why those values end up wrong.
Is this already a problem in the underlying XCOFF file debug info,
or is this just read in incorrectly by GDB/BFD at some point?
Can you debug a bit more exactly where the wrong values come from?
Is there some AIX tool you can use to look at the XCOFF debug info
directly to compare with what GDB is reading?
Bye,
Ulrich
next prev parent reply other threads:[~2023-04-21 13:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-07 11:00 [PATCH] Fix call functions command bug in 64-bit programs for AIX Aditya Kamath1
2022-11-08 13:30 ` Ulrich Weigand
2022-11-11 17:53 ` Aditya Kamath1
2022-11-14 15:54 ` Ulrich Weigand
2022-11-14 17:32 ` Aditya Kamath1
2022-11-14 18:19 ` Ulrich Weigand
2022-11-14 18:28 ` Aditya Kamath1
2022-11-14 18:43 ` Ulrich Weigand
2022-11-14 18:52 ` Aditya Kamath1
2022-11-14 19:10 ` Ulrich Weigand
2022-11-16 11:27 ` Aditya Kamath1
2022-11-16 15:15 ` Ulrich Weigand
2022-11-16 18:07 ` Aditya Kamath1
2022-11-16 18:30 ` Tom Tromey
2022-11-17 12:54 ` Ulrich Weigand
2022-11-24 17:56 ` Aditya Kamath1
2022-11-24 18:15 ` Tom Tromey
2023-04-14 7:38 ` [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning Aditya Kamath1
2023-04-14 14:45 ` Tom Tromey
2023-04-17 13:08 ` Aditya Kamath1
2023-04-17 13:16 ` Aditya Kamath1
2023-04-18 10:12 ` Ulrich Weigand
2023-04-21 13:00 ` Aditya Kamath1 [this message]
2023-04-24 15:44 ` Ulrich Weigand
2023-04-27 10:13 ` Aditya Kamath1
2023-04-27 12:23 ` Ulrich Weigand
2023-04-27 10:14 ` Aditya Kamath1
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CH2PR15MB35442EE01CC59A685984437FD6609@CH2PR15MB3544.namprd15.prod.outlook.com \
--to=aditya.kamath1@ibm.com \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=sangamesh.swamy@in.ibm.com \
--cc=simon.marchi@efficios.com \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).