From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by sourceware.org (Postfix) with ESMTPS id AAC313955CA8 for ; Fri, 13 May 2022 14:45:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AAC313955CA8 X-IronPort-AV: E=McAfee;i="6400,9594,10346"; a="269990448" X-IronPort-AV: E=Sophos;i="5.91,223,1647327600"; d="scan'208";a="269990448" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2022 07:45:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,223,1647327600"; d="scan'208";a="567224297" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orsmga007.jf.intel.com with ESMTP; 13 May 2022 07:45:50 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Fri, 13 May 2022 07:45:49 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Fri, 13 May 2022 07:45:49 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27 via Frontend Transport; Fri, 13 May 2022 07:45:49 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.100) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.27; Fri, 13 May 2022 07:45:49 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hqJlZgRp5hA0+/0uXOPfpAPK6XB5gnu64VKIWgWOg4PhlpBO1GxIYjz65RrEWSasAQ4ES/69hnHy6CUSKf2g6gzSsJVz7NfXhLe6aGCOO/rDypnV94huMifNtdaU89LZK32+taUgoqy2aBuAAnjrD5sqg+cBf4MuUC2th9GzOmdCqj566gLwlNsV2R3nWp+sJS4ekKBiJhffP2nXybtgkD36pfh6zSbKLoP5I/07BcOo9C4d4bRwyBd7s5oJ1ynSqXTwec6DsbWNeuSgqznzJOvaVkCzy+Qrhyj8ZCnyYrNs4I0J1yeBA/C2xPjjKjxgi/crkfeL2vHkDeP8KygKCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NaYkwg0FQDCEnj5hnWSjXVKH1vnYSwDptYnBjtm6Ua4=; b=Lg/yRi6yRXdpOEbMwcA2sLPT3azoFvEGj1UAxlc7DlVf/H1pcVKfsfyWoFLjkv8zOkAe9zkktyG604SNp5A4HO2clW6g8bJf9UkHc5Aum3iT90Im0uLFE2yVlZVdwBG7QL9HR0l7awJW2wqlTS3NuUY70B9wXCxBF8+czYo/aGzlzQuVEQ5pK7iDJmIwg6ZggBG11Gnr1wgiXSeeZQBrpHyjlcp/R8VnpnIsi1tE/Go6Sf4NRnhoO/4SuHyK3VZWDOasDWrd7sWZmCRzofcjVW2wrODC7FODLUyqzv7yKQsUns1XARbnPVFVAFIkQIhuHVtbksQ6KG/L1xNBlSGdTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from CY4PR1101MB2071.namprd11.prod.outlook.com (2603:10b6:910:1a::10) by CY5PR11MB6259.namprd11.prod.outlook.com (2603:10b6:930:24::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5250.14; Fri, 13 May 2022 14:45:48 +0000 Received: from CY4PR1101MB2071.namprd11.prod.outlook.com ([fe80::403f:f9f0:74f2:c5b9]) by CY4PR1101MB2071.namprd11.prod.outlook.com ([fe80::403f:f9f0:74f2:c5b9%10]) with mapi id 15.20.5250.014; Fri, 13 May 2022 14:45:47 +0000 From: "Kempke, Nils-Christian" To: "Kempke, Nils-Christian" , Tom Tromey , "Kempke, Nils-Christian via Gdb-patches" Subject: RE: [PATCH 2/2] gdb: Resolve dynamic target types of pointers. Thread-Topic: [PATCH 2/2] gdb: Resolve dynamic target types of pointers. Thread-Index: AQHYDG8c7kvyvhMx8kmJfwRdCntUeKyNVSWUgAjaHkCAW3+e8oAFrftQgAAAcNA= Date: Fri, 13 May 2022 14:45:47 +0000 Message-ID: References: <20220118132626.3786176-1-nils-christian.kempke@intel.com> <20220118132626.3786176-3-nils-christian.kempke@intel.com> <87k0e2tsga.fsf@tromey.com> <87ee1y1fzn.fsf@tromey.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.401.20 dlp-reaction: no-action x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fb2bbdca-870b-44d3-afba-08da34ef4496 x-ms-traffictypediagnostic: CY5PR11MB6259:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: a3Qf/hPQK+iqMrVASBIdF6o321DGYGtYoQ3Oguvr0KAh9EWLW13nCUI3kHpu9qdcs5JwGCLNglWNr3MNuRSaxeuKACQChNLmPeSVvgn96g6Lo/T/u1gId8Z+CTgg04zrvW0fOAmP189Bg7T9Ggx8a8MX9wLVL/fk9OW8Y/CdPG2fDCuDMXiyOm1wjF5/aDamItP5rgXqO0t6/P7tHySBoRhOss9doNG+NOvGHvkpQ3FSrWMN5vXiba1loyV28v57JY5td5jOMC08KhFLWDnRolqMkIhRKLrSLh6/TdMD7Rz1tJ9RNSxR81IMkcFHOXAsyI7SLZCKMG/K22imNqUuIFENhGOAzPQLtY+wBN1VH/PLUbYWwMMPmtgJHOQt9dE3fcn1q1uKP9y/V4V4pFQIywsxDtk3PW/eZu41lLYa6JolYzSn8GAiGiTDOgukVNMYUxm2e/eASlNFcau+hsT97e4c3PcQ3nk21Tacbx2JOvtlcAYskDVmTAfR2Nk+eOOsmXE/S7GW4RWDIxiMHsKUFteutdlXI9dzN7jtQEZ8L1QO2s8MfCot76BecRJJcuVPMSU2QdPSf8jJHXZ0BFBAlnaTYpkL7nl0ZtlsOyF0KaL1IiD2eT0QUG/IiN9YoynPVtpNZQRKAm1DxZB2I4f7VgSfrs7D6mxQAsl7ff50h/oWCbiAo+HatPMLvLz996i0dbNN2IMvITIj8JvZoMHbpg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR1101MB2071.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(186003)(316002)(2906002)(8936002)(33656002)(122000001)(52536014)(5660300002)(82960400001)(83380400001)(71200400001)(38070700005)(66476007)(53546011)(76116006)(64756008)(508600001)(6506007)(8676002)(66446008)(66946007)(66556008)(9686003)(26005)(110136005)(86362001)(38100700002)(55016003)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?q56Z1yd5Nq6V8YyA+nvxf8ZUU2ZzhHXFEowDR6ax86mBM04Xf7dJpY8IJYO0?= =?us-ascii?Q?pny0GZRpyC+bbt8+OS7ao+XbSF+4bxFexoNEzu+5bgQOeYdZqdcGSti5TdmR?= =?us-ascii?Q?VHyW2XoIiz2rm1xHBcLz+ZxmDjlxu3qsEqP0/I/o2zhfdxhZbYIByinVz6hK?= =?us-ascii?Q?IJTshGtQARiZ1NdS6xaa33/tKToShqHA1dBSf+hgx2TOxxzfkOe2TG5yPHaS?= =?us-ascii?Q?DdbyUHwgjWD//idretxGY34AAQkNEXBNtxzHthLuIUZY0T0d0oj6Ms8qp77y?= =?us-ascii?Q?g9yFFEXcPoDWZpN7WBfF85J3GJz89OJKLuuuuHi7YVgOqXIptBVlE+YTTRLw?= =?us-ascii?Q?/yr/+FwjiUXskMcMGON2dWUupxNrbqtHnBxkJ+FWYgpbIu18uXNGaig8phmW?= =?us-ascii?Q?9wOMtgmee5n55pySpAt17pXXZS1sGgZsqAbMGlLOXBfzfSqxB9NY2XcgSEWc?= =?us-ascii?Q?tXuSbghfoSJU4SCvpHbkZmYmG8VwN7AanBZx5n7E+37kAgd0txaqYUXylZBc?= =?us-ascii?Q?2rxOYOGE5nV2bPp5z18MmIYBpABjIzj5WkHL34xkn1tj4GiEX92yiyYoj3lO?= =?us-ascii?Q?DVqcjM6jygUgH2RkSWX/rpub7rZkmxeKxzIBxR4sMOxpscfxskqgCO+BlgC5?= =?us-ascii?Q?pq1rwOqLvnDvUQDPJ+ZpDZmWizeoHqKX3mPJAT2EJN0F8Qq7d4//DZoC/eI/?= =?us-ascii?Q?QHzDEFA17Stw0h1iVAsQE7qgjm9aHCAFb9r70DWDwEt9Lc4zPBzzuVakUDDl?= =?us-ascii?Q?zFBdSms4dHMJ+CXZk+UGcN0TMqUkxwdtSPxpMse5YhpLZpjLgCuDYZQ8vNCN?= =?us-ascii?Q?prvS0mY19mN9jkuYgbx0pSofwJIoI6dLM3D+Os3x0Xj1oINIFY5uBj8nJoyc?= =?us-ascii?Q?ZUBfzaLmwNGN8Iz9CRwBOGa0lFV5iSTc10ML8T3aMyR7oTLS/q1HYUO5zcuS?= =?us-ascii?Q?UWQwizYk/6WMkDup2sz+4YhT6it3Nhy8XiMulRT23C+PYyL81aI+qiJrZ6qt?= =?us-ascii?Q?SuAaQPG6ZVeUVDjIUcZBCG6IELAYYDFWeLUeXr3/ctwkZ/pyukgtiPfMl/dG?= =?us-ascii?Q?TvVrHjy2NWczK8ffmhknb+LZZ2tGGsUw5aWvCZhv6WVgDFnXtb4CLv52fSOu?= =?us-ascii?Q?S0npK3qiliRofjDoyxtV6BuuOIUqPq7wlhtkRGVaxLL0mMsAR+mGUid39bGR?= =?us-ascii?Q?l36JLWDL8tcbg2lhXevGcBKUcJ8FItSi8OFCgnOL1lcms2csCfuukhnaBV7U?= =?us-ascii?Q?1KEwjjJUOTJchueilYrFKHba0IQR5VtocAAhJsEtNvWhT6WOptEQYdXvkG3b?= =?us-ascii?Q?bZc9Fk4l9IXcqGqmnUObVqtUvYBnKgSmIONNmrxi2R6/5hSdYhmoL031F54Z?= =?us-ascii?Q?jHF5WFkMvAI+64ZcleniqMTsyGUg7udWoYi1ZNvetGTfw+ypiFTEgpjG6Lep?= =?us-ascii?Q?auqvSPyY3C5hr/eRhkZFXM1czs7zhdmKTanDn6v9G/gg2/upbnHHqFNr+0WZ?= =?us-ascii?Q?4BCyrpbhqg+fqZgroKx1CtxtC/KkRYhArt0YNQNrYkswcZBJ4HI5ntlXi51F?= =?us-ascii?Q?m2d6BhQG/apSu2YO8i6y66dhXiM8UQHpYHtijUchlW6gd1i4916PCjoBh3cC?= =?us-ascii?Q?0R9HRcFqhL3xH7ECl2cgqJYnM1hPNh1Ft/jXxXZoFT/Dp+d2eTnwMbE/BM63?= =?us-ascii?Q?ChblwUjbGlt1v+an9qaophVUk5R60fjlvvXek4SOsVJ9h4HIyhHC+unDtg6S?= =?us-ascii?Q?yE13EAwpuC56iK1xs7dHg/oopHtjHHs=3D?= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR1101MB2071.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fb2bbdca-870b-44d3-afba-08da34ef4496 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2022 14:45:47.8588 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1d6Aa20iFM6uJzc55nBNQOEyOqjrwp8RoHKneWjx2qHObEOCbwad/uRVtCcr2y1tsKSXsd2bnVNycu/apBozfIDwdByWzplD0zqpfDtLsTY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR11MB6259 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2022 14:45:55 -0000 Hi, Sorry for this first message, something went wrong there.. Again. First of all, thanks for the feedback! > -----Original Message----- > From: Gdb-patches christian.kempke=3Dintel.com@sourceware.org> On Behalf Of Kempke, Nils- > Christian via Gdb-patches > Sent: Tuesday, April 19, 2022 8:59 AM > To: Tom Tromey ; Kempke, Nils-Christian via Gdb- > patches > Subject: RE: [PATCH 2/2] gdb: Resolve dynamic target types of pointers. > = > > > > >> > + if (type->code () =3D=3D TYPE_CODE_PTR && is_dynamic_type > (type)) > > >> > + { > > >> > + CORE_ADDR addr; > > >> > + if (nullptr !=3D TYPE_DATA_LOCATION (TYPE_TARGET_TYPE > (type))) > > >> > + addr =3D value_address (val); > > >> > + else > > >> > + addr =3D value_as_address (val); > > >> > > >> This seems weird to me. When does value_as_address fail? > > > > > This if else has been introduced because of the way ifort/icc describe > > pointers > > > vs. gcc/gfortran and icx/ifx. > > > > > <1> DW_TAG_variable > > > <> DW_AT_type: > > > <> DW_AT_location: (location of the pointer) > > > <1> DW_TAG_pointer_type > > > DW_AT_type: > > > <1> DW_TAG_array_type > > > <> DW_AT_type: > > > <> DW_AT_data_location: (location of the array) > > > <2> DW_TAG_subrange_type > > > > > Fortran: > > > > > <1> DW_TAG_variable > > > <> DW_AT_type: > > > <> DW_AT_location: (location of the pointer) > > > <1> DW_TAG_array_type > > > <> DW_AT_type: > > > <> DW_AT_data_location: (location of the array) > > > <2> DW_TAG_subrange_type > > > > > When printing this pointer to array in gfortran/ifx the pointer print > function > > is > > > not actually called - since the DWARF does not emit a pointer here. > > Instead, > > > the normal array print is invoked which will use the > DW_AT_data_location. > > > So we do not run into this same problem > > > > I still do not understand, sorry. > > > > For me this looks like two different types. In one situation, the type > > is a pointer to an array. In the second, it's just an array. So, I > > would expect them to print differently. > > > > Are you saying these should print identically? If so, that's fine -- > > but then it seems like something to do in the Fortran code, not in > > c-valprint.c. > = > Yes, that is true. So, in Fortran pointers are just aliases for the under= lying > objects First about the pointers in general: They are emitted as two different types but represent the same object in the code. The fact that ifort emits pointer-to-array here is, I think, less ideal than a plain array type. In Fortran a pointer is more like an alias to the underlying object. It sh= ould be thought of as a type with the pointer attribute, rather than a c pointer. I= t is handled the exact same way the as object itself. E.g. printing an associat= ed pointer-to-array would just print the array - as if one had printed that instead. There is some hidden dereferencing going on when using them (and as compared To C pointers) - so yes, imo ideally the print should be the same. But this would not be addressed with the sent patch. The changes in the patch only affect the resolution of the target dynamic type (thus the cases in the tests). I think the explanation I gave above was quite bad as well and in my initial submission of this patch I am not sure whether I had 100% understood this part as I do think of it now. I will try again: In GDB when we end up at the point where the dynamic type is to be resolved, the address we will get from CORE_ADDR addr =3D value_as_address (val); will, if the underlying type had a DW_AT_data_location, be the result of the evaluation of that DW_AT_data_location. This is fine for pure arrays, but with pointer to arrays this is problematic. The reason for this is, as= described in the DWARF5 5.18.1: 1 5.18.1 Data location ... 5 The DW_AT_data_location attribute may be used with any type that provides 6 one or more levels of hidden indirection and/or run-time parameters in i= ts 7 representation. ... ... 10 This location description will typically begin with DW_OP_push_object_ad= dress which 11 loads the address of the object which can then serve as a descriptor in = subsequent 12 calculation. For an example using DW_AT_data_location for a Fortran 90 a= rray, see 13 Appendix D.2.1 on page 292. (the example on 292 I think is quite helpful) In the example on page 292, not only the DW_TAG_data_location but also the DW_TAG_subrange_type require the evaluation of an expression containing the DW_OP_push_object_address. The object address that should be used for these evaluations is the one of the original variable, in the example the v= ariable 'arrayvar', which has its own DW_AT_location attribute. It is especially n= ot the result of the array type's DW_AT_data_location. = The example describes this as Page 295: 7 For b), for each dimension of the array (only one in this case), go in= terpret the 8 usual lower bound attribute. Again this is an expression, which again = begins 9 with DW_OP_push_object_address. This object is still arrayvar, from st= ep 1, 10 because we have not begun to actually perform any indexing yet where b) is evaluation of the lower bounds of the array. Here the 'still ar= rayvar' tells to use the DW_AT_location. Going back to ifort: <1> DW_TAG_variable <> DW_AT_type: <> DW_AT_location: (location of the pointer) <1> DW_TAG_pointer_type DW_AT_type: <1> DW_TAG_array_type <> DW_AT_type: <> DW_AT_data_location: (location of the array using DW_OP_push_object_ad= dress) <> DW_AT_allocated: (using DW_OP_push_object_address) = <2> DW_TAG_subrange_type <> DW_AT_TYPE: <> DW_AT_lower_bound (using DW_OP_push_object_address) <> DW_AT_upper_bound (using DW_OP_push_object_address) With such a location description we'd not be able to correctly evaluate the DW_TAG_subrange_type as GDB would try to use the DW_AT_data_location (gotten when evaluating value_as_address) instead of the DW_AT_location of the original variable (which would be value_address (..)). Thus, when we s= ee that the underlying type has a DW_AT_data_location we use the value_address instead the value_as_address here. I don't think this is a perfect solution really.. But I am not sure how to = handle this better atm. I would be ok with removing this check from the patch for now,= and just always use value_as_address.. This part though for sure would need a w= ay better commit message I feel like. Ifx, gfortran and flang do not emit these kind of types as far as I know (r= emoving the check for DW_AT_data_location will also only mess with the icc/ifort pa= ssrate of the tests). I guess, in order to properly resolve a target type of a po= inter one would have to got through all its dynamic attributes that are about to be r= esolved and check, whether these need the address of the object or not. > > Maybe in the code the check for TYPE_DATA_LOCATION is a proxy for > > checking that the pointer is a pointer to a Fortran array? I guess I > > could understand that, but it doesn't seem like a good approach, because > > what if some C compiler starts emitting this? If a C compiler would start emitting this, I think we would also get proble= ms when trying to resolve the dynamic target type - as the location of the act= ual array is not the location of the pointer. But that also assumes again that using DW_AT_data_location for the target type will in general come with using DW_ OP_push_object_address for the target type, too. So, this checking is somehow a proxy, but for realizing that the resolving = the target type will need the object_address of the original pointer. = > > >> I'm curious why the code added here is not also needed in f-valprint= .c. > > > > > The reason here is simply that Fortran does not have this implemented > for > > > Itself. Instead the fortran f_langugage inherits from language_defn = (the > all > > > languages base class) which simply delegates the value-print to > > > c_value_print / so changing it there suffices. > > > > If Fortran-specific printing is needed, this will have to change. That is true. Dereferencing pointers before printing them would be such a t= hing, but I think handling the pointer-to-array DWARF construct above should appl= y to more than just the ifort Fortran pointers - any compiler could start emitti= ng the same construct and we'd get problems at the same spots when trying to resolve th= e types. At least I don't see how DWARF spec would stand in the way of compilers emi= tting this. Currently I only know of ifort emitting this construct where the resolving = of the subrange upper and lower bounds actually requires the original pointer addr= ess. I know that icx also would emit pointers to arrays in the same way ifort do= es, but here, the subrange (afaik) does not depend on the object address and does n= ot use DW_OP_push_object_address. So overall, this currently only happens with ifrot and in Fortran. Sorry for the bad first explanation. Thanks! Nils Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva = Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928