* [PATCH] Fix gdb.base/code_elim.exp failures for PowerPC 32-bit
@ 2014-07-01 9:46 Luis Machado
2014-07-08 1:53 ` Samuel Bronson
0 siblings, 1 reply; 4+ messages in thread
From: Luis Machado @ 2014-07-01 9:46 UTC (permalink / raw)
To: 'gdb-patches@sourceware.org'
[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]
Hi,
Another case of slight variations between targets and compiler options.
gdb.base/code_elim.exp assumes the linker generates the same sections
for all architectures. For x86, this works fine and the testcase binary
code_elim2 contains the .data section to hold our initialized global int
variable.
For PowerPC 32-bit though, the small initialized global int variable is
sent to the .sdata section as an optimization. Since there is no more
data to store, the .data section doesn't get created.
GDB complains about the lack of such a section and expect doesn't like
seeing that warning, which results in a couple failures for powerpc.
One of them:
[snip]
add-symbol-file gdb.base/code_elim2 0x200000 -s .data 0x210000 -s .bss
0x220000^M
add symbol table from file "gdb.d/gdb.base/code_elim2" at^M
.text_addr = 0x200000^M
.data_addr = 0x210000^M
.bss_addr = 0x220000^M
(y or n) y^M
Reading symbols from gdb.base/code_elim2...warning: section .data not
found in gdb.base/code_elim2^M
done.^M
(gdb) FAIL: gdb.base/code_elim.exp: order1: add-symbol-file code_elim2
0x200000
I have tweaked the testcase sources a little to hold a bigger
initialized global variable, forcing the linker to create a regular
.data section in order to prevent GDB's warning. The testcase still runs
fine, but now PowerPC 32-bit sees full passes on this one.
I thought about tweaking the optimization options, but that would need
to be target-specific, which is more cumbersome.
Luis
[-- Attachment #2: code_elim.diff --]
[-- Type: text/x-patch, Size: 1125 bytes --]
2014-07-01 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/code_elim2.c (my_global_array): New global variable.
(my_global_func): Use global variable.
diff --git a/gdb/testsuite/gdb.base/code_elim2.c b/gdb/testsuite/gdb.base/code_elim2.c
index 64ecc04..3eb8d5c 100644
--- a/gdb/testsuite/gdb.base/code_elim2.c
+++ b/gdb/testsuite/gdb.base/code_elim2.c
@@ -15,6 +15,9 @@
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
+/* Declare a global variable of reasonable size to make sure the .data section
+ is created, preventing a warning from GDB when manually loading symbols. */
+int my_global_array[6] = {4, 8, 15, 16, 23, 42};
int my_global_symbol = 42;
static int my_static_symbol;
@@ -28,7 +31,7 @@ main ()
int
my_global_func ()
{
- my_static_symbol = my_global_symbol;
- my_global_symbol = my_static_symbol + my_global_symbol;
+ my_static_symbol = my_global_symbol + my_global_array[6];
+ my_global_symbol = my_static_symbol + my_global_symbol + my_global_array[3];
return my_global_symbol;
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] Fix gdb.base/code_elim.exp failures for PowerPC 32-bit
2014-07-01 9:46 [PATCH] Fix gdb.base/code_elim.exp failures for PowerPC 32-bit Luis Machado
@ 2014-07-08 1:53 ` Samuel Bronson
2014-07-08 5:48 ` Luis Machado
0 siblings, 1 reply; 4+ messages in thread
From: Samuel Bronson @ 2014-07-08 1:53 UTC (permalink / raw)
To: lgustavo; +Cc: 'gdb-patches@sourceware.org'
Luis Machado <lgustavo@codesourcery.com> writes:
> For PowerPC 32-bit though, the small initialized global int variable
> is sent to the .sdata section as an optimization. Since there is no
> more data to store, the .data section doesn't get created.
>
> GDB complains about the lack of such a section and expect doesn't like
> seeing that warning, which results in a couple failures for powerpc.
Hmm, seems like a silly thing to complain about ...
> One of them:
>
> [snip]
> add-symbol-file gdb.base/code_elim2 0x200000 -s .data 0x210000 -s .bss 0x220000^M
> add symbol table from file "gdb.d/gdb.base/code_elim2" at^M
> .text_addr = 0x200000^M
> .data_addr = 0x210000^M
> .bss_addr = 0x220000^M
> (y or n) y^M
> Reading symbols from gdb.base/code_elim2...warning: section .data not
> found in gdb.base/code_elim2^M
> done.^M
> (gdb) FAIL: gdb.base/code_elim.exp: order1: add-symbol-file code_elim2
> 0x200000
>
> I have tweaked the testcase sources a little to hold a bigger
> initialized global variable, forcing the linker to create a regular
> .data section in order to prevent GDB's warning. The testcase still
> runs fine, but now PowerPC 32-bit sees full passes on this one.
Is tweaking the testcase really the best approach here? Shouldn't GDB
just be less picky?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] Fix gdb.base/code_elim.exp failures for PowerPC 32-bit
2014-07-08 1:53 ` Samuel Bronson
@ 2014-07-08 5:48 ` Luis Machado
2014-07-08 8:43 ` Pedro Alves
0 siblings, 1 reply; 4+ messages in thread
From: Luis Machado @ 2014-07-08 5:48 UTC (permalink / raw)
To: Samuel Bronson; +Cc: 'gdb-patches@sourceware.org'
On 07/08/2014 02:52 AM, Samuel Bronson wrote:
> Luis Machado <lgustavo@codesourcery.com> writes:
>
>> For PowerPC 32-bit though, the small initialized global int variable
>> is sent to the .sdata section as an optimization. Since there is no
>> more data to store, the .data section doesn't get created.
>>
>> GDB complains about the lack of such a section and expect doesn't like
>> seeing that warning, which results in a couple failures for powerpc.
>
> Hmm, seems like a silly thing to complain about ...
>
>> One of them:
>>
>> [snip]
>> add-symbol-file gdb.base/code_elim2 0x200000 -s .data 0x210000 -s .bss 0x220000^M
>> add symbol table from file "gdb.d/gdb.base/code_elim2" at^M
>> .text_addr = 0x200000^M
>> .data_addr = 0x210000^M
>> .bss_addr = 0x220000^M
>> (y or n) y^M
>> Reading symbols from gdb.base/code_elim2...warning: section .data not
>> found in gdb.base/code_elim2^M
>> done.^M
>> (gdb) FAIL: gdb.base/code_elim.exp: order1: add-symbol-file code_elim2
>> 0x200000
>>
>> I have tweaked the testcase sources a little to hold a bigger
>> initialized global variable, forcing the linker to create a regular
>> .data section in order to prevent GDB's warning. The testcase still
>> runs fine, but now PowerPC 32-bit sees full passes on this one.
>
> Is tweaking the testcase really the best approach here? Shouldn't GDB
> just be less picky?
>
Either solution is fine with me, but the warning is actually somewhat
informative since the .data section is relatively common.
The testcase, on the other hand, is not designed to behave the same in
all architectures.
Luis
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] Fix gdb.base/code_elim.exp failures for PowerPC 32-bit
2014-07-08 5:48 ` Luis Machado
@ 2014-07-08 8:43 ` Pedro Alves
0 siblings, 0 replies; 4+ messages in thread
From: Pedro Alves @ 2014-07-08 8:43 UTC (permalink / raw)
To: lgustavo, Samuel Bronson; +Cc: 'gdb-patches@sourceware.org'
On 07/08/2014 06:47 AM, Luis Machado wrote:
> On 07/08/2014 02:52 AM, Samuel Bronson wrote:
>> Luis Machado <lgustavo@codesourcery.com> writes:
>>> add-symbol-file gdb.base/code_elim2 0x200000 -s .data 0x210000 -s .bss 0x220000^M
^^^^^^^^^^^^^^
[snip]
>>> Reading symbols from gdb.base/code_elim2...warning: section .data not
>>> found in gdb.base/code_elim2^M
[snip]
>> Is tweaking the testcase really the best approach here? Shouldn't GDB
>> just be less picky?
>>
>
> Either solution is fine with me, but the warning is actually somewhat
> informative since the .data section is relatively common.
That doesn't make sense in this context. GDB is not being picky -- the
warning is coming out because the user _explicitly_ specified an
address for the .data section, not because .data is special
in any way.
--
Pedro Alves
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-07-08 8:43 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-01 9:46 [PATCH] Fix gdb.base/code_elim.exp failures for PowerPC 32-bit Luis Machado
2014-07-08 1:53 ` Samuel Bronson
2014-07-08 5:48 ` Luis Machado
2014-07-08 8:43 ` Pedro Alves
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox