public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ibhagat at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/109161] New: Bad CTF generated for stub in function scope
Date: Thu, 16 Mar 2023 20:45:46 +0000	[thread overview]
Message-ID: <bug-109161-4@http.gcc.gnu.org/bugzilla/> (raw)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109161

            Bug ID: 109161
           Summary: Bad CTF generated for stub in function scope
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ibhagat at gcc dot gnu.org
  Target Milestone: ---

$ cat t.c 
void set_cpu_arch (void) {
    typedef struct arch_stack_entry {
        const struct arch_stack_entry *prev;
    } arch_stack_entry;
    static arch_stack_entry *arch_stack_top;
}

$ gcc -gctf -g3 -c t.c

$ objdump --ctf=.ctf t.o will hang.

The hang is because the compiler spits incorrect CTF. 

Byte offsets (which point to the location of the various sub-sections in the
CTF section) encoded in the CTF header as seen via poke:
  ...
  cth_funcoff=0U#B,
  cth_objtidxoff=4U#B,
  cth_funcidxoff=4U#B,
  cth_varoff=8U#B,
  cth_typeoff=8U#B,
  cth_stroff=96U#B,
  ...

 -- The generated CTF section has one function object, and no variables as can
be seen from the offsets in the header. This is OK. 
 --There are however, generated types; Further, a subset of which are incorrect
(see below).

(poke) ctf_dump_all_types(ctf)
Types:
   1:  (kind 1) integer void (size 0) (signed)
   2:  (kind 5) function set_cpu_arch --> ID 1: (kind 1) integer void (size 0)
   3:  (kind 6) struct arch_stack_entry (size 8)
        [0U#b] prev (ID 5)
        [0U#b]  (ID 3)
   4:  (kind 12) const  --> ID 3: (kind 6) struct arch_stack_entry (size 8)
   5:  (kind 3) pointer  --> ID 4: (kind 12) const  --> ID 3: (kind 6) struct
arch_stack_entry (size 8)

[Problem #1] A struct with two members, one of which is unnamed.  The type as
defined by the user has one member named prev in the struct => The generated
CTF is incorrect.
[Problem #2] Well, why is there any generated CTF at all ?  Both the variable
and the defined type are function-scope; In CTF, only top-level types,
functions, variables are to be described.

             reply	other threads:[~2023-03-16 20:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-16 20:45 ibhagat at gcc dot gnu.org [this message]
2023-03-19 23:11 ` [Bug debug/109161] " pinskia at gcc dot gnu.org
2023-03-28 23:01 ` nix at esperi dot org.uk
2023-04-12 21:19 ` ibhagat at gcc dot gnu.org

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=bug-109161-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).