From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) by sourceware.org (Postfix) with ESMTPS id 7627F3858D37 for ; Tue, 16 Jan 2024 22:09:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7627F3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7627F3858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::c2b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705442953; cv=none; b=rHcKxtWl1wfYXyKnyRZRu9RCMv9i+Jgm8uVqMThSbzwXr1h2Lr5ill879dc+5M9Kl0gpXZ11TeUJIK8fs1wqj0Fb7DFgrjNZNOjurQ/OZi1VBRMMent6u74cohtVlpW0K6NukvBmO9xm6EEQ4pqwI7jxkzDQv03wQv9eIN5WANE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705442953; c=relaxed/simple; bh=bsU6tJYDqY2To0o3oB6byKrfgNaeep9Cl8PM1VfM1zQ=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=uuAqawyAlPK8/jv0axAn1gX8j2bZIdFa//9YjgUZsUYboBRBVIDG7IMSDd8Y5yY1m2wRunpnjdNO7+9kleWvwGFmBYewc5sp0fBazsX91ktxLRER3FhuRNpnx55nsYaFYIJ+4UB3i0QNtzOLXgb0hCBE/vE7jcc8xwQlgHObLGY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oo1-xc2b.google.com with SMTP id 006d021491bc7-598b8dd877dso2515729eaf.3 for ; Tue, 16 Jan 2024 14:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705442946; x=1706047746; darn=sourceware.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=RYH2c8w7siCk/fOoZ3vtw6AmaXckH3xzhv73RpKc4C0=; b=h0BMomXj6amzC6CCOGROYQjBARUsYPHtKf8Yr3sxJeXmTfav+chtkst5eRyPFwWBQN rjt6pq47hXUdUfYCY5w7Gbk9PfDZHEjHyEcbsQpnbVvisqZdA8OTOoF5SuVdVYDPekO8 ggLFQlUgBN8gfU1TBWKAB0NZF/r/NLH8IWpZDMVk5gV7zP+3FskEMs79lYRJiZC7Fq+D JnW9YrBQlaBC8UKpl7Q9RczMWFq3UwdqGGe+krcvGdXg1vSVprqrb0As++pJCcyl3fmO XZY/fdt85IC8DGmH8ne19fpS11kx2qNmtK61NXzylMMg+boGgiPHve6vTYG9ExzPJm8x wlKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705442946; x=1706047746; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RYH2c8w7siCk/fOoZ3vtw6AmaXckH3xzhv73RpKc4C0=; b=EsJJjC16WyRbnTJ7OwHPrewNcMenWSUjtCPFfqO0uI6jpOhWauD6d6p0lpmDeycjkp Q+ul8+lrn8Nbd5/lN0MJPGFWrfzKf9pm00plT1q4pDwc+1ZDyTkDN4uoHoD+QNVd3BT+ lWCy6yCOjzxTF9rs/K8Z/kGbf+G6h0n9j5JRyxz7hWxKu1rjK4oCKY2fKATcxOZYmDkx t3bVZyYwmLZWPrx+2xAva2fKZ+duS3HABosSbQfazXxgXGQfLZusRIHr0yu+Jb97GwB7 dMOYlFPt8Wxbnmlg1cf9jRcmyrsNraWFmD6K87sk1nUpgNsCoyxiCW5zy9pKctOG0h+q yT/w== X-Gm-Message-State: AOJu0YxCP00YNewBxeM9+nRTmNMjSkhoMHhHZlLLCd2xlM0nm5r9V4Y2 U+CDKUYBN3Q88iNveMf/PEk7yxN56HA= X-Google-Smtp-Source: AGHT+IFT6WE5tvjJepPVaqlOZlLaZz7e59rhREX/BITtC9rwvdnjKjrutN4ITDz7mQItDeoYHNHoQA== X-Received: by 2002:a05:6358:910c:b0:175:83f1:b661 with SMTP id q12-20020a056358910c00b0017583f1b661mr12781947rwq.27.1705442946208; Tue, 16 Jan 2024 14:09:06 -0800 (PST) Received: from emerald.. ([2804:10f8:433d:9800:dbd3:15aa:77f3:48c8]) by smtp.gmail.com with ESMTPSA id bw39-20020a056a0204a700b005c66b54476bsm9135821pgb.63.2024.01.16.14.09.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jan 2024 14:09:05 -0800 (PST) From: Matheus Branco Borella To: gdb-patches@sourceware.org Cc: eli@gnu.org Subject: Re: [PATCH v4] Add support for creating new types from the Python API Date: Tue, 16 Jan 2024 18:27:23 -0300 Message-Id: <20240116212722.10251-1-dark.ryu.550@gmail.com> X-Mailer: git-send-email 2.40.1 In-Reply-To: <83v87taz0f.fsf@gnu.org> References: <83v87taz0f.fsf@gnu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > How can that work? AFAIU, most architectures only allow pointers of > certain sizes, some allow pointers of just one size. E.g., what > happens if I create a 16-bit pointer on a 64-bit target? My intention is primarily to make it possible to construct such types, assuming the given configuration is valid. In this case it would be the consumer of the API who would be responsible for guaranteeing what they are doing is valid. Regardless, as far as I could gather, GDB doesn't really seem to care if values whose types have TYPE_CODE_PTR have sizes that are valid in the target architecture. `unsigned_pointer_to_address`, as well as all the `*_pointer_to_address` functions I could find by grepping for uses of `set_gdbarch_pointer_to_address` in the code are perfectly fine just reading the data in the pointers as if they were type->length()-sized integers. And mostly the same goes for their `*_address_to_pointer` counterparts, except for large values being clipped (including extra function pointer information). But I believe that behavior should be fairly unsurprising if you're creating a pointer with the wrong size. So, to answer your question, AFAICT it would just treat it as an address stored in an (u)int16_t.