public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Aditya Kamath1 <Aditya.Kamath1@ibm.com>
To: Tom Tromey <tom@tromey.com>, Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Cc: Tom Tromey <tom@tromey.com>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>,
	"simon.marchi@efficios.com" <simon.marchi@efficios.com>
Subject: RE: [PATCH] Modify align-c/align-c++ test case for AIX
Date: Tue, 21 Mar 2023 07:01:03 +0000	[thread overview]
Message-ID: <CH2PR15MB354499A1C5600A3F3BD23270D6819@CH2PR15MB3544.namprd15.prod.outlook.com> (raw)
In-Reply-To: <87zg8bave2.fsf@tromey.com>

[-- Attachment #1: Type: text/plain, Size: 7167 bytes --]

Hi Ulrich, Tom and Community,

>So is this some linker optimization where those global variables
>are just removed if they are not used?  Are the variables still
>present in the *symbol* table (not DWARF)?

>If it is a linker optimization, maybe this can be switched off
>via some command line option?

Yes Ulrich. It is a linker optimisation.
So we need to use these options while compiling.

bash-5.1$ gcc -g -gdwarf ~/gdb_tests/simple_test.c -o ~/gdb_tests/simple_test -Wl,-bnogc  -lodm -lcfg
bash-5.1$ cat ~/gdb_tests/simple_test.c
#include <stdio.h>
int global_variable1 = 1;
int global_variable2 = 2;
int main(){
        int local_variable = 1;
        printf ("Simple print statement \n");
        return 0;
}
bash-5.1$
bash-5.1$ ./gdb ~/gdb_tests/simple_test
GNU gdb (GDB) 14.0.50.20230221-git
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64-ibm-aix7.2.0.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
https://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
    http://www.gnu.org/software/gdb/documentation/.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/aditya/gdb_tests/simple_test...
(gdb) p global_variable1
$1 = 1
(gdb)

We are able to access it now.
Dwarf dump output of the above debug code.
<1><  347>      DW_TAG_variable
                DW_AT_name                  global_variable1
                DW_AT_decl_file             2
                DW_AT_decl_line             2
                DW_AT_decl_column           5
                DW_AT_type                  <175>
                DW_AT_external              yes
                DW_AT_location              DW_OP_addr 0x20000570
<1><  378>      DW_TAG_variable
                DW_AT_name                  global_variable2
                DW_AT_decl_file             2
                DW_AT_decl_line             3
                DW_AT_decl_column           5
                DW_AT_type                  <175>
                DW_AT_external              yes
                DW_AT_location              DW_OP_addr 0x20000574

If we do not use the options -Wl,-bnogc  -lodm -lcfg during compilation , then the dwarf dump is as shown below.

bash-5.1$ gcc -g -gdwarf ~/gdb_tests/simple_test.c -o ~/gdb_tests/simple_test
bash-5.1$ ~/dwarfdump -a ~/gdb_tests/simple_test

.debug_info
……….
<1><  347>      DW_TAG_variable
                DW_AT_name                  global_variable1
                DW_AT_decl_file             2
                DW_AT_decl_line             2
                DW_AT_decl_column           5
                DW_AT_type                  <175>
                DW_AT_external              yes
                DW_AT_location              DW_OP_addr 0xffffffff
<1><  378>      DW_TAG_variable
                DW_AT_name                  global_variable2
                DW_AT_decl_file             2
                DW_AT_decl_line             3
                DW_AT_decl_column           5
                DW_AT_type                  <175>
                DW_AT_external              yes
                DW_AT_location              DW_OP_addr 0xffffffff
<1><  409>      DW_TAG_subprogram
                DW_AT_external              yes
                DW_AT_name                  main
                DW_AT_decl_file             2
                DW_AT_decl_line             4
                DW_AT_decl_column           5
                DW_AT_type                  <175>
                DW_AT_low_pc                0x10000518
                DW_AT_high_pc               92
                DW_AT_frame_base            <expr length 0>

So clearly, linker optimises out unused global variables. More about the same can be read in the documentation {https://www.ibm.com/docs/en/aix/7.1?topic=l-ld-command }

So I was thinking if we can pass these to our site.exp file if the target is AIX:

set CC_FOR_TARGET "/opt/freeware/bin/gcc"
set CXX_FOR_TARGET "/opt/freeware/bin/g++"
set CXXFLAGS_FOR_TARGET "-O0 -w -g -gdwarf -maix64"
set CFLAGS_FOR_TARGET "-O0 -w -g -gdwarf -maix64"

with the options -Wl,-bnogc  -lodm -lcfg.

We also use -maix32 for testing in 32 bit mode as well.

I think this would be a better patch and in AIX we will not be seeing so many failures as we see now instead of the initial proposed ifdef patch. Only thing is we need to add this in a file which I am not aware of such that if the target is AIX we need to add these flags in the site.exp file so that while running test cases we get this file to pass these flags during the compilation of them.

Since I am a beginner to the same I need your guidance and expertise here. I wish to fix this for AIX and GDB community. Currently I manually add these flags which is not correct. Which MakeFile or a gdb.exp file can I do the same? Kindly let me know. Also let me know what you think of the explaination.

>>                 DW_AT_location              DW_OP_addr 0xffffffff

>In addition to what Ulrich said, I wonder if this behavior should have a
>workaround in the gdb DWARF reader.  E.g., gdb could use producer
>sniffing to detect when this might happen, and then mark these symbols
>as optimized out, or something along those lines.

Hi Tom,

Thank you for this suggestion. So I was thinking to spilt this patch into two.

One for the passing of flags in AIX for the site.exp file in testsuite.

Another to tell the AIX users that “You have not passed the flags and hence the linker has optimised out this variables, kindly compile with the same”.  Your idea is nice to tell our users, since many of AIX folks will not be aware of the linker optimisation.

Can you or anyone in the community suggest me an example in the GDB code that uses this producer sniffing we can do the same.

Kindly let me know.

Have a nice day ahead.

Thanks and regards,
Aditya.

From: Tom Tromey <tom@tromey.com>
Date: Saturday, 18 March 2023 at 3:33 AM
To: Aditya Kamath1 <Aditya.Kamath1@ibm.com>
Cc: Tom Tromey <tom@tromey.com>, Ulrich Weigand <Ulrich.Weigand@de.ibm.com>, gdb-patches@sourceware.org <gdb-patches@sourceware.org>, Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>, simon.marchi@efficios.com <simon.marchi@efficios.com>
Subject: [EXTERNAL] Re: [PATCH] Modify align-c/align-c++ test case for AIX
>>>>> Aditya Kamath1 <Aditya.Kamath1@ibm.com> writes:

>                 DW_AT_location              DW_OP_addr 0xffffffff

In addition to what Ulrich said, I wonder if this behavior should have a
workaround in the gdb DWARF reader.  E.g., gdb could use producer
sniffing to detect when this might happen, and then mark these symbols
as optimized out, or something along those lines.

Tom

  reply	other threads:[~2023-03-21  7:01 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-10  8:57 Aditya Kamath1
2023-03-10 14:46 ` Tom Tromey
2023-03-13 13:04   ` Aditya Kamath1
2023-03-13 14:10     ` Ulrich Weigand
2023-03-15 11:52       ` Aditya Kamath1
2023-03-15 12:45         ` Tom Tromey
2023-03-16  7:01           ` Aditya Kamath1
2023-03-17 17:06             ` Ulrich Weigand
2023-03-17 22:03             ` Tom Tromey
2023-03-21  7:01               ` Aditya Kamath1 [this message]
2023-03-21  7:41                 ` Ulrich Weigand
2023-03-21 11:05                   ` Pedro Alves
2023-03-21 14:17                   ` Tom Tromey
2023-03-21 14:26                     ` Ulrich Weigand
2023-03-29 11:28                       ` Aditya Kamath1
2023-03-29 13:36                         ` Pedro Alves
2023-03-31 12:29                           ` Aditya Kamath1
2023-04-04 13:24                             ` Aditya Kamath1
2023-04-05 16:33                             ` Pedro Alves
2023-04-06 13:15                               ` Aditya Kamath1
2023-04-06 16:18                                 ` Pedro Alves
  -- strict thread matches above, loose matches on Subject: below --
2023-03-10  8:56 Aditya Kamath1
2023-03-10 10:08 ` 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=CH2PR15MB354499A1C5600A3F3BD23270D6819@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).