Bug 29468 - GDB test gdb.base/ctf-constvars.exp fails.
Summary: GDB test gdb.base/ctf-constvars.exp fails.
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: testsuite (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: 13.1
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-08-10 20:30 UTC by Carl E Love
Modified: 2022-10-12 16:09 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
gdb.log on x86_64-linux (2.13 KB, text/x-log)
2022-10-12 15:55 UTC, Tom de Vries
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Carl E Love 2022-08-10 20:30:26 UTC
The gdb test gdb.base/ctf-constvars.exp fails with gcc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1)

The test is for the new CTF debug support in gdb/gcc.

In discussing the issue with the test author, they indicate that the issue may be with ld.  

When the test is run with the command:

 make check RUNTESTFLAGS='GDB=/home/carll/bin/gdb gdb.base/ctf-constvars.exp  ' > out

two files are generated in gdb/testsuite/outputs/gdb.base/ctf-constvars, they are ctf-constvars0.o  and ctf-constvars.  If you check for the CFT information in the files using:

objdump --ctf ctf-constvars > ctf-constvars.dump
objdump --ctf ctf-constvars0.o > ctf-constvars0.o.dump

you will find a section "Variables".  in ctf-constvars0.o.dump the section contains values, i.e.

  Variables:
    caveat -> 0x7: (kind 11) const char *volatile (size 0x8) (aligned at 0x8) -> 0x5: (kind 3) const char * (size 0x8) (aligned at 0x8) -> 0x2: (kind 12) const char (size 0x1) (aligned at 0x1) -> 0x1: (kind 1) char (format 0x2) (size 0x1) (aligned at 0x1)
    cavern -> 0x3c: (kind 12) const volatile char *const (size 0x8) (aligned at 0x8) -> 0x3b: (kind 3) const volatile char * (size 0x8) (aligned at 0x8) -> 0x4: (kind 12) const volatile char (size 0x1) (aligned at 0x1) -> 0x3: (kind 11) volatile char (size 0x1) (aligned at 0x1) -> 0x1: (kind 1) char (format 0x2) (size 0x1) (aligned at 0x1)

 etc.

However in the final binary, ctf-constvars.dump all you see is:

  Function objects:

  Variables:

  Types:
    0x1: (kind 1) char (format 0x2) (size 0x1) (aligned at 0x1)
  etc.

Basically, the Variables section is blank in the final binary output.  Apparently, the ld tool didn't include the data as expected.

The result of all this is the gdb test fails as it can't find the needed debug information.
Comment 1 Tom de Vries 2022-09-20 15:43:09 UTC
-Wl,-ctf-variables improves things for me:
...
$ objdump --ctf outputs/gdb.base/ctf-constvars/ctf-constvars | grep vox
    vox -> 0x3: (kind 11) volatile char (size 0x1) (aligned at 0x1) -> 0x1: (kind 1) char (format 0x3) (size 0x1) (aligned at 0x1)
    0x21d: vox
...

That still doesn't fix things:
...
$ gdb -q -batch outputs/gdb.base/ctf-constvars/ctf-constvars -ex "print vox"
'vox' has unknown type; cast it to its declared type
...
because the dwarf info is in the way.

After stripping the dwarf info:
...
$ strip --strip-debug outputs/gdb.base/ctf-constvars/ctf-constvars
...
we have:
...
$ gdb -q -batch outputs/gdb.base/ctf-constvars/ctf-constvars -ex "print vox"

$1 = 66 'B'
...
Comment 4 Carl E Love 2022-10-12 15:39:48 UTC
I pulled down the latest gdb on PowerPC, specifically a Power 10 system running 
Fedora release 36 (Thirty Six).


The test still fails.  I see the following errors still:

(gdb) break -qualified main
Breakpoint 1 at 0x10000698
(gdb) run 
Starting program: /home/carll/GDB/build-hardware-watchpoint/gdb/testsuite/outpu\
ts/gdb.base/ctf-constvars/ctf-constvars 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, 0x0000000010000698 in main ()
(gdb) print vox
'vox' has unknown type; cast it to its declared type
(gdb) FAIL: gdb.base/ctf-constvars.exp: print vox
ptype vox
type = <data variable, no debug info>
(gdb) FAIL: gdb.base/ctf-constvars.exp: ptype vox
print victuals
'victuals' has unknown type; cast it to its declared type
(gdb) FAIL: gdb.base/ctf-constvars.exp: print victuals
ptype victuals
type = <data variable, no debug info>
...

I will take a look and see if I can figure out why this is not fixing the issue on PowerPC.
Comment 5 Tom de Vries 2022-10-12 15:55:20 UTC
Created attachment 14394 [details]
gdb.log on x86_64-linux
Comment 6 Tom de Vries 2022-10-12 15:56:43 UTC
Ok, reopening then until we've got this figured out.

Thanks for verifying.
Comment 7 Carl E Love 2022-10-12 16:06:11 UTC
OK, my bad.  I did the testing in the wrong directory.  Argh.  So, when I build and test using the correct build directory on PowerPC I get

(gdb) run 
Starting program: /home/carll/GDB/binutils-gdb-next-reverse-bkpt-over-sr/gdb/te\
stsuite/outputs/gdb.base/ctf-constvars/ctf-constvars 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, 0x0000000010000698 in main ()
(gdb) print vox
$1 = 66 'B'
(gdb) PASS: gdb.base/ctf-constvars.exp: print vox
ptype vox
type = volatile char
(gdb) PASS: gdb.base/ctf-constvars.exp: ptype vox
print victuals
$2 = 67 'C'
(gdb) PASS: gdb.base/ctf-constvars.exp: print victuals
ptype victuals
type = volatile unsigned char
(gdb) PASS: gdb.base/ctf-constvars.exp: ptype victuals
print vixen
$3 = 200
(gdb) PASS: gdb.base/ctf-constvars.exp: print vixen
ptype vixen
type = volatile short

,,,

type = const volatile unsigned char [2]
(gdb) PASS: gdb.base/ctf-constvars.exp: ptype vegetation
testcase /home/carll/GDB/binutils-gdb-next-reverse-bkpt-over-sr/gdb/testsuite/g\
db.base/ctf-constvars.exp completed in 0 seconds

                === gdb Summary ===

# of expected passes            56
Executing on host: /home/carll/bin/gdb -nw -nx -iex "set height 0" -iex "set wi\
dth 0" --version    (timeout = 300)

So, yes the patch does fix the error on PowerPC.  Sorry for the confusion.
Comment 8 Tom de Vries 2022-10-12 16:09:24 UTC
(In reply to Carl E Love from comment #7)
> OK, my bad.  I did the testing in the wrong directory.  Argh. 

Eh, it happens :)

> So, yes the patch does fix the error on PowerPC.  Sorry for the confusion.

Wonderful, thanks again for verifying.