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: Thu, 27 Apr 2023 10:13:29 +0000 [thread overview]
Message-ID: <CH2PR15MB35444CC7F9D1F798D407217FD66A9@CH2PR15MB3544.namprd15.prod.outlook.com> (raw)
In-Reply-To: <149511a0bc674c71674357a19915d8f454abb63a.camel@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 5115 bytes --]
Hi Ulrich, Tom and community,
>My understanding, and that is apparently confirmed by the
>text in the GNU stabs documentation here:
>https://sourceware.org/gdb/download/onlinedocs/stabs/Transformations-On-Global-Variables.html
>is that the "address" va lue in the debug entry is not used,
>but the actual address should be taken from the .text entry.
>Now I'm not sure why this doesn't work correctly, but this
>may be a place to investigate further.
>(One interesting thing to note is that the names do not match
>exactly, as the .text entry has the leading '.' that is used
>on ppc64 ... maybe this throws off some of the stabs logic?)
Thank you so much for this explanation. So here is our investigation further.
This __new_exitfn is coming from libgcc. Libgcc is -g compiled with stabs debugging format.
bash-5.1$ dump -tov /opt/freeware/lib/libgcc_s.a | grep __new_exitfn
[32] m 0x200007e8 .data 1 unamex __new_exitfn_called
[8978] m 0x100002cc .text 2 extern .__new_exitfn
[8981] m 0x00000000 debug 0 fun __new_exitfn:F1=*2=xsexit_function:
[9039] m 0x00000000 debug 0 gsym __new_exitfn_called:G13=14=@s64;r14;0;01777777777777777777777;
[9053] m 0x20000060 .data 1 extern __new_exitfn_called
We see that gcc 10 has this debug symbol which is copied in every binary compiled with gcc 10.
But if I use gcc 11 whose debug format is dwarf and -g compiled this symbol is as below. And I do not see that bug anymore.
dump -tov /opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/11/libgcc_s.a | grep __new_exitfn
[32] m 0x200007d8 .data 1 unamex __new_exitfn_called
[2813] m 0x100003e4 .text 2 extern .__new_exitfn
[2834] m 0x20000050 .data 1 extern __new_exitfn_called
So folks who will use this version of gcc will not face this problem.
So this looks like a gcc problem..
From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Date: Monday, 24 April 2023 at 9:14 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:
>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 seems to be these numbers are not actual addresses,
which looks like the root cause of the problem.
In fact, looking e.g. at "__new_exitfn" in the detailed dump below:
>[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
We see that there is an actual symbol (in the .text section)
at address 0x100007a8, covering 416 byte (until 0x10000948).
*In addition*, there is a "debug" (stabs) symbol giving the
type of that function. This also has an address field, but
this is simply zero.
My understanding, and that is apparently confirmed by the
text in the GNU stabs documentation here:
https://sourceware.org/gdb/download/onlinedocs/stabs/Transformations-On-Global-Variables.html
is that the "address" value in the debug entry is not used,
but the actual address should be taken from the .text entry.
Now I'm not sure why this doesn't work correctly, but this
may be a place to investigate further.
(One interesting thing to note is that the names do not match
exactly, as the .text entry has the leading '.' that is used
on ppc64 ... maybe this throws off some of the stabs logic?)
Bye,
Ulrich
next prev parent reply other threads:[~2023-04-27 10:13 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
2023-04-24 15:44 ` Ulrich Weigand
2023-04-27 10:13 ` Aditya Kamath1 [this message]
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=CH2PR15MB35444CC7F9D1F798D407217FD66A9@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).