From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
To: Aditya Kamath1 <Aditya.Kamath1@ibm.com>,
"tom@tromey.com" <tom@tromey.com>
Cc: "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: Fri, 17 Mar 2023 17:06:30 +0000 [thread overview]
Message-ID: <8071ae5aa27c5eaa8466ed72672eb306966b1e56.camel@de.ibm.com> (raw)
In-Reply-To: <CH2PR15MB3544F4B5F9136E36A6AF2C07D6BC9@CH2PR15MB3544.namprd15.prod.outlook.com>
Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:
>>I think the question is why is it -1 here.
>>Like, is it wrong in the DWARF? Or did the DWARF reader do something
>>wrong? Or was some runtime offset incorrectly applied? Etc.
>
>The problem is from the DWARF itself. Our GDB code is picking up things correctly.
>Specifically when we do not use the global variables or the global variable
>section it those variables are assigned 0xffffff by the linker.
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?
If not, then I guess something like your original patch does
seem a reasonable solution ...
Bye,
Ulrich
next prev parent reply other threads:[~2023-03-17 17:06 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 [this message]
2023-03-17 22:03 ` Tom Tromey
2023-03-21 7:01 ` Aditya Kamath1
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=8071ae5aa27c5eaa8466ed72672eb306966b1e56.camel@de.ibm.com \
--to=ulrich.weigand@de.ibm.com \
--cc=Aditya.Kamath1@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).