Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Jan Vraný via Gdb" <gdb@sourceware.org>
To: "gdb@sourceware.org" <gdb@sourceware.org>
Cc: "tom@tromey.com" <tom@tromey.com>
Subject: Question about struct type* ownership
Date: Wed, 8 Jan 2025 13:32:33 +0000	[thread overview]
Message-ID: <078460761931d0f4a1574e18173e51464ee4ccb2.camel@labware.com> (raw)

Hi Tom, 

in response to my "Python JIT API" series [1] you pointed
out that there are rules about type ownership [2] I was not
aware of: 

> The issue is that in gdb there is a hidden rule: an objfile-specific
> type may only refer to other types from that objfile or to arch->
specific
> types.  Arch-specific types may only refer to other arch-specific
types.

While working on addressing this concern, more questions poped up:

Let's say I'd like to create new function type "int(struct s)", where
type "int" is arch-owned and "struct s" is objfile-owned. Am I correct
thinking that resulting function type should be objfile-owned? 

Generally speaking, if composing new type out of other types, if at
least one of the types is objfile-owned then the new type must by
also objfile-owned (by that very objfile), right? 

Looking at lookup_function_type_with_arguments, it allocated new
function type is always "owned" by whoever "owns" the return type
(first param to lookup_function_type_with_arguments). So if I'm correct
about the above, I'd have to extend lookup_function_type_with_arguments
to pass down type allocator (like in create_array_type). Or is there
a better way?

Also, when experimenting with the example above, I realized that 
the arch-owner of "int" struct type* is a different struct gdbarch *
then gdbarch associated with objfile-owner of "struct s" type
(i mean, pointer values are different).
While I would think it is okay to compose new type from types owned by 
two distinct gdbarchs from lifecycle POV, it still puzzles me why
there are two different gdbarch instances (both are i386:x86-64)?

Thanks! 

Best, Jan



[1]:
https://inbox.sourceware.org/gdb-patches/20241121124714.419946-1-jan.vrany@labware.com/
[2]:
https://inbox.sourceware.org/gdb-patches/87y10ba1ms.fsf@tromey.com/



             reply	other threads:[~2025-01-08 13:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-08 13:32 Jan Vraný via Gdb [this message]
2025-01-09  0:30 ` Tom Tromey
2025-01-09 11:02   ` Jan Vraný via Gdb

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=078460761931d0f4a1574e18173e51464ee4ccb2.camel@labware.com \
    --to=gdb@sourceware.org \
    --cc=Jan.Vrany@labware.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