From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by sourceware.org (Postfix) with ESMTPS id D7A3A385841B for ; Fri, 4 Nov 2022 11:58:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D7A3A385841B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=oracle.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=oracle.com Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 2A4B6Oqi030334; Fri, 4 Nov 2022 11:58:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=corp-2022-7-12; bh=60BeRDqQwKFqjh3sI7p1o08IuGwuBgDeO7+1KpjgF7Y=; b=KiiUkNRLt2LH/ODd0/WZxqoEgHj0zB4HAyJ3PPBj+D1KAHRFVAD8itwyWnI9ddR6nVPG THT14oY+uhEuARgMTAwjoqlPvkhsiIKuzwPZZIhZgzu/umCncg3yMFq6i3kPLT0mXEsT 6MA9KbEH2eDO86E9I/r7slvsWuNu7BUSDVyRKV9ZrMyu2tLaAvNWKfpohoqfMh5YhEV4 50oY66Gk9dxn7ILulhxilOflU+IVZ8rP91OEFMB8bu31ZVdGYIA35Q/Lz32g5OJyFGoy q6WaVIS82PqSpPfqYFrZlEW0qU7PW5mLH0AThxlvtNXAQb99uZhlhXOXzTAFYnMfV7Fg eA== Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3kgty37mp1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 04 Nov 2022 11:58:34 +0000 Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 2A4BmDNn029449; Fri, 4 Nov 2022 11:58:33 GMT Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam04lp2049.outbound.protection.outlook.com [104.47.73.49]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3kmpr8qu9x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 04 Nov 2022 11:58:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RGncwFCkYUA++IGht0B0O1XwvHzTGUfESZaneTywvwEy3cj4jjS1ljeD/PEvUxFj88eOjDxeajjqiMz98y00z9lY7DFJCraFVSZ9uW5ZJWLWlxNx3cY34CuQfKdhdDfkS/TllzXL3qdiUht493FpnMVzjS9LrHpW3I7NeCqTfy4GFkBx5LwbqeSjKU+lfT5GrFAmPKoZ8cveIX5SjkfqaBGHZILgRwRP2sjuJJKWAVNYsk6m1PbVN24+3QgBko/OATqLcAQFuiut7TSyaEqZiKqbLOjttGXcwcOQ2f2jEJB/WljT0qJ1PejEKSXxyB+va6YshMti2cNwGDQI16mMww== 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=60BeRDqQwKFqjh3sI7p1o08IuGwuBgDeO7+1KpjgF7Y=; b=m3QAULUtsXHQsU0ZhMzoFhuUY4c61gbQ4gdhH2i3iN85TyNPJInWylCOKNxXz+zZslCo+HKzOtrofFqY0oU0b/GRdm6h7tF0gZqYbDXMQwFz0G4i+z6MfTSwh+FUnt46XhAtnLeYt1gSN4VGIykp8MYvJX0FyF08+1TcD4TQ8Azhhdp4G15symu6BMSHJlYrNzI7LWNibNSZgFBS/3rfvQtunEnBPTi558Sg42OiMgb2d03lPd9veS1GxQEgsGNxtekM/sTffSUGxHBjwNbj5zLElGd38luXAwotBi7lHEQ5KKYyxBOrjtn7CrFrS2ps4Qc3dYPdzVr1AYPlSBWZhQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=60BeRDqQwKFqjh3sI7p1o08IuGwuBgDeO7+1KpjgF7Y=; b=gEOj8Yku0OEf5aWhKXmgKiFYEnS52ZHETasy1cKwFN8gd8a50kflkuZ+PJAADFbKOLJVg6NeWVCqeAzN45ae2d6kfh3CqvJivFjMlfzOVq2aIqyBHKPot8Izc933KgHaRdXiY0B1twk+nevTtCpiI3MvVw6fILl65pN3kAzwET4= Received: from BYAPR10MB2888.namprd10.prod.outlook.com (2603:10b6:a03:88::32) by BN0PR10MB5143.namprd10.prod.outlook.com (2603:10b6:408:12c::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.22; Fri, 4 Nov 2022 11:58:30 +0000 Received: from BYAPR10MB2888.namprd10.prod.outlook.com ([fe80::5095:b148:8def:1049]) by BYAPR10MB2888.namprd10.prod.outlook.com ([fe80::5095:b148:8def:1049%5]) with mapi id 15.20.5791.020; Fri, 4 Nov 2022 11:58:29 +0000 From: "Jose E. Marchesi" To: gdb-patches@sourceware.org Cc: Mike Frysinger , elena.zannoni@oracle.com, indu.bhagat@oracle.com Subject: [Mike Frysinger] Re: [PATCH, V3 10/15] gdb: sim: buildsystem changes to accommodate libsframe Date: Fri, 04 Nov 2022 13:02:33 +0100 Message-ID: <87y1srrkpy.fsf@oracle.com> Content-Type: multipart/mixed; boundary="=-=-=" X-ClientProxiedBy: AS9PR06CA0328.eurprd06.prod.outlook.com (2603:10a6:20b:45b::31) To BYAPR10MB2888.namprd10.prod.outlook.com (2603:10b6:a03:88::32) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BYAPR10MB2888:EE_|BN0PR10MB5143:EE_ X-MS-Office365-Filtering-Correlation-Id: 9f8c15bf-64b1-4f85-14f7-08dabe5be3b9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: cofieHWIkPGy8XhxGyDLsehf2vU0Zaks73vW/l2u8DbqtIBmC9YDVMGHKkonDE1ELuFHJ88OTimpzILyDhuLxXfHqhBjoYrMIbyfNNICvbzs6Rwo9UDxc0egm0o+/wmXAFT8m2rFBgxdVNs96IRzrV1/XXWiwyjvZ0Yr0Hr/JxGqSACXGyGY5C9flFc1AVFe49UwAChGtw3Rwwa9Mq11DrNLRaY7cuy9Ukrx5qGHWtfKU994lVKH0hvxucBb4TZ4vN2D8DJwqmXUQ8xPD9ze9lmETSdbvfCoOdx8krXhXMfzEIh5C22KetWiDjPulWKUvwsOJ7APFDiTy/zVDZ8Y3qrqNRu6V+/oYtP5ww4ELKFdUa1DCUq11wEee3kHX+e+NTzDdJKTSdEBBxXdeZjfcdK7FDnHhSwpawUgqEM+aKgl+NvlGdGw9QNtSNE16S998TgLEb1hQhRSYR1a65Io0I1QmXjawpzHLgc/HgJVzOEmnN6sMRrkvRYC8RD+N4AEJxs1rRfUKiHwcAtUN++kdz3UygeLzdtBXK/A3rZ2BEUHln8MY9IfvCLQj5wFweffVQiNkYQSdoicr8U0iNiIJytFjARrPDBt39I/5efUM92txYvoVUtvomlaJgKzjfwjEqdPv0enuLw0JkUMOe+GNQaXpN7bLpZzBWgB3j/ZF8wTV6eHWlUEWEgUcWgr0t5XnfJSa3w7RR8zarfY7TZuLg== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR10MB2888.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(376002)(136003)(366004)(346002)(39860400002)(396003)(451199015)(6666004)(83380400001)(5660300002)(107886003)(38100700002)(41300700001)(86362001)(6916009)(36756003)(478600001)(316002)(2906002)(26005)(6486002)(186003)(66556008)(4326008)(6506007)(53546011)(66476007)(8676002)(66946007)(33964004)(2616005)(8936002)(6512007)(44144004);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?2jlkKB6gr1V2CYKS4MKnZyJ1c/FzZjl1gNG23g+VBYtmVj0ry/42QMug+5qG?= =?us-ascii?Q?37ZIf7fnCuPWRKxfYsBdCDVgk7BMC9HwS58hl/PV1Ft6TuD00amFS6zBIzRw?= =?us-ascii?Q?+Fw48TtpriVUbvXHy/6UTvNBvzYQSuxtj562LVLmyNAP9zoCnsUvK7mrdZVa?= =?us-ascii?Q?Di77oc/iMcNoiejtypJ4hYPh8/SCHA1mmD/qbwwH3dmKGcotawkyrSeOhK2D?= =?us-ascii?Q?bSzXWoARBa44ceWbgpReEju7UZIwkaUlXXydzflPxojWbn1jaEQS5jvth0el?= =?us-ascii?Q?m82fY4mu5B/HeJZOQBLb8nrvaL+run8AkERYlP0bGT49ooob0lnWm6d40ems?= =?us-ascii?Q?xOGWocwzuiwoi5KrxF5l2S//Xt2w2kGAvFzZ2iIlFDsIsYYwyyF+ZhScwKzu?= =?us-ascii?Q?mADYQpN3hWJGlOVPrWIQxo3lUirMpbRApnb7teBtvOqF4Y74Nk3C6EZd6u+8?= =?us-ascii?Q?nDRvYgjoKSkgWpbiQvd2UVoPwcpCQwSaaNrBIVjxQ7Uha0HTkPIXeNMyk5pr?= =?us-ascii?Q?Ns7J5tfeNhf1m04axuYau/pItct8xkAdPRREFz2/nH4WktGIUG4hyR3ufspU?= =?us-ascii?Q?9fE+dNFikD8IYh5bvroipffcy57sc324OjqO96Wmj032gfJbTK3ruofiAkSE?= =?us-ascii?Q?a3n0W/XlKwZfPATH/eECAQj/H7lQdsIugksgsEu+ycdaQ9oZMjgYVGNR0v13?= =?us-ascii?Q?vZiyBUxwOa13Hjn8z3mpu3H8jFCXBM9khvQyDCGEX2qLH02hxs/QqO97rvdu?= =?us-ascii?Q?WnkMjrggKhwQB+jna0bLGz/Z08hToRKeGYej1q4+pAUWpFiGxII/jNsxvJtS?= =?us-ascii?Q?PwoTic6lquCmFQTuucSGoR9kGu2ftXhz7mwjFtwzNUUdZyVmIzYBPgmfqesY?= =?us-ascii?Q?jRpbCCgw8GECzgY0EfJJfoz3+6Df4j15hGzweGdC5xpz8sKiPtMm2ATi9vsh?= =?us-ascii?Q?imbjyuaJk/SCpfaLrArPvhOmzXJhJOBZCdUOexUCh/7ZKCNeBbAs+ydzIPWz?= =?us-ascii?Q?EsUyhlgz1zX4MU2xefkq265K9zTbvE1VtYyIiL4IwInEBfR1X4e714qlLbWI?= =?us-ascii?Q?TDysMDk4w3nBUOwMRRYOumh2li2aHkTjwly1E6Chda7es3MPCrwuc82fDLxu?= =?us-ascii?Q?8VV//z/THW7ijYRMzPEjbVhti/PL2+jyifRZbTIgXIbtNrewgkagzhuEItWD?= =?us-ascii?Q?iC43QO+HMd+9Pg1AEzKiKaB52UFYIYRPFuEGA7W6ZNl001df0W1Y33+mdaft?= =?us-ascii?Q?kSGcXHZbdtfHHruavJ2RppA+DxyuRdpfGXPfmdFPx7nMxmYuOsIA6zQyVd46?= =?us-ascii?Q?NAgzYK1dH54xlVlAAMqzuUOyNLFvUyKaBTX336B+48DV7bpmN1JImi5ffA2/?= =?us-ascii?Q?uuhKU1n2GkBQtLXaOPpuQ1k89EjLSxYqk3x4jittKqYSKC0bOxOBuilTjCbN?= =?us-ascii?Q?VKHZl6mn+0lldg87+IdPP4AluSgh0uE1I0OhKqyRPzPe4q7JDRAhvMLghACt?= =?us-ascii?Q?SqNAAC7LI1W8QtpCrcUhKYExj2a09iOMg0rmxUqtgZe8r6jcAMXxSx5pktrQ?= =?us-ascii?Q?uQ4S4rPKuDf+nkwg4Xe15b3wqq+aNOabgrl8zEALCh+V0lLE4JXrj+veYLWt?= =?us-ascii?Q?9w=3D=3D?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9f8c15bf-64b1-4f85-14f7-08dabe5be3b9 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB2888.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Nov 2022 11:58:29.9455 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zw1a3AmHTstlyuN6vVjuE0TUAmgaPCQhwC/UvQCKWewpcjKcdAlG+f5OWEOPg2Kc5iJ6ZvQbm1Isq3sXFtPmcg5miOqWLcAE51EXh+JRyoc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR10MB5143 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-04_07,2022-11-03_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 suspectscore=0 adultscore=0 phishscore=0 spamscore=0 malwarescore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211040080 X-Proofpoint-ORIG-GUID: 7csX39pJQhV4nf3ArPZVy0PtIKhy7mlN X-Proofpoint-GUID: 7csX39pJQhV4nf3ArPZVy0PtIKhy7mlN X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP 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: --=-=-= Content-Type: text/plain Hello people! What is the opinion of the GDB maintainers about the necessity of libtoolizing GDB before accepting changes like the following: In gdb/configure.ac: if test x${enable_static} = xno; then LIBSFRAME="-Wl,--rpath,../libsframe/.libs ../libsframe/libsframe.a" SFRAME_DEPS="../libsframe/.libs/libsframe.so" else LIBSFRAME="../libsframe/.libs/libsframe.a" SFRAME_DEPS="$LIBSFRAME" fi AC_SUBST([LIBSFRAME]) AC_SUBST([SFRAME_DEPS]) In gdb/Makefile.in: LIBSFRAME = @LIBSFRAME@ SFRAME_DEPS = @SFRAME_DEPS@ [...] CLIBS += $(LIBSFRAME) CDEPS += $(SFRAME_DEPS) Note that both the in-tree libs libctf and libbacktrace are currently handled the same way. I have to admit I find myself split here. As a maintainer, I would share Mike's reservations (maybe not as strongly, but I get it) expressed in the forwarded email below. Corporate wise, however, we would really need to close the "add sframe support to binutils" chapter before opening the "libtoolize GDB" chapter or we can find ourselves in trouble. But first things first: how do you people feel about libtoolizing the rules in gdb/Makefile.in so GDB can handle the in-tree libtool libraries in a more graceful way? -------------------- Start of forwarded message -------------------- Date: Thu, 3 Nov 2022 22:27:34 +0700 From: Mike Frysinger To: "Jose E. Marchesi" Cc: binutils@sourceware.org Subject: Re: [PATCH, V3 10/15] gdb: sim: buildsystem changes to accommodate libsframe --=-=-= Content-Type: multipart/signed; boundary="==-=-=" --==-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On 02 Nov 2022 20:11, Jose E. Marchesi wrote: > > Hi Mike, Indu. > > >> > On 30 Oct 2022 00:44, Indu Bhagat via Binutils wrote: > >> >> [Changes in V3] > >> >> - Additional diff in sim/ppc/Makefile.in to accommodate libsframe. > >> >> This is needed to ensure --enable-targets=all continues to build. > >> >> - Addressed review comments by Mike Frysinger. > >> > > >> > this doesn't seem to actually address my comments. you're still poking > >> > the internals of libtool by accessing files under .libs/. > >> > >> gdb does not use libtool yet. > > > > you have access to the source. you can change these things. > > > > also, gdb & sim are sep projects. > > I see gdb/configure.ac uses the same strategy in order to locate the > in-tree libbacktrace.a and libctf: > > if test "${enable_libbacktrace}" = "yes"; then > LIBBACKTRACE_INC="-I$srcdir/../libbacktrace/ -I../libbacktrace/" > LIBBACKTRACE_LIB=../libbacktrace/.libs/libbacktrace.a > AC_DEFINE(HAVE_LIBBACKTRACE, 1, [Define if libbacktrace is being used.]) > else > LIBBACKTRACE_INC= > LIBBACKTRACE_LIB= > fi > > [...] > > if test x${enable_static} = xno; then > LIBCTF="-Wl,--rpath,../libctf/.libs ../libctf/.libs/libctf.so" > CTF_DEPS="../libctf/.libs/libctf.so" > else > LIBCTF="../libctf/.libs/libctf.a" > CTF_DEPS="$LIBCTF" > fi > > With corresponding substitutions in gdb/Makefile.in. > > I agree it would be better to have GDB libtoolized so it could refer to > the .la libraries directly thus avoiding internals, but could that be > done in a separated patch set, also covering the other cases? > > In the meanwhile, Indu could change her patch in order to look for > libsframe.so in gdb/configure.ac instead of gdb/Makefile.in, as it is > done for the other libs. Then we libtoolize. "the code is already in bad shape, so let's add more kindle to the fire" isn't a great strategy. hoping someone else will come and clean up the mess also isn't a great strategy ... usually that means it never gets cleaned up, and the tech debt just continues to build. so "let's do this as a followup" almost always translates into "i don't want to do it, and it's never actually going to happen, so let me merge anyways". i'm not saying that's necessarily the intention of the person making such a request, just that that's the practical result in my experience in the vast majority of cases. people, no matter how well intentioned, are busy, so without any pressing leverage (like "this is required if you want to merge"), it never improves. to be clear, i'm not a global gdb maintainer, so if you can convince one of them, then certainly they override. i am NAKing adding any such hacks to the sim code though. although that's a bit moot since i've already posted patches to clean up its libtool usage which means it doesn't need any changes for libsframe logic. -mike --==-=-= Content-Type: application/pgp-signature; name=signature.asc Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ0FBZEZpRUV1UUsxSnhNbCtK S3NKUnJVUVdNN24rZzM5WUVGQW1OajNlVUFDZ2tRUVdNN24rZzMKOVlGeVFnLytJdnIyR0srV09P K3h3S0dnWDhHelJqWm5ESUtGL0kzUGUyZ200SHQ1dzRvZm5KVmZMcVRZSG1PcgpuaGlZNzY3dDVj RzhpR2xWY0hDRXVPRU5aa1VmRU1kVDFsWjZkeGpzREoxZHVJTjRZVXRVY0ZlQ0diY2hqc2kzCkFJ dkJTTFlGVFViRnlUQmpURmFMSTI0R21tUnJjSVI1TU9mdjNoWlZKYzVwTmxVN3NQTFdCbUdmTFNK RHVFYm8KZlBDNjEzQ3RaWWNML0xXRmdMY3c3eTkvQkpoYmNrUms4T1ZxRFg4ZnIvSTJQWHNSZ2I5 OHRDWWJ0Y1JMdEFvYQpoRFVOWHVmbnZQQjlsWjFjT0NtZG14c3dwaFAwQTRkdkEybHJRazZCRjZR L0FoUlpyQVc5bHBxcUdiUFV0R2hNCkM0aEhoWWZzNkpTTkEyVkx3VWtEMkNaVVBDZGhBRFBwams2 RU56NmNUeTdLbUNVY2NMUWkrVVN2M284MDl3N0cKRG1tTUordnVlalRwaVNTUEhRQnBLcDJiMHly RHJxeWZXNmdheFBCWDJQbWI1Y0dPbEE5N1RsOEhjR0xoVjBtdQpIeVhtN3JWR0VPa003UjU1NTZI RXZKb0JnOStqMThuUWlRWUVyNUVPRlBqTk9zRVVpSHdFU1hGZW5EUGRBazB4CkxWcTZJaU5IbkFi ZkJjbTFWUGtDWUVPMGtMMUJpVDNRYkJPbFZPVFlYTlUwMmJJVzJ5Q0wzRityRVFxK0lRdjMKNjBN eCtzZVdyckdsTVRNVEZoZ2oxQnEvWnRYZUUvZ0dsZFBiUlVHWTBRSm5EcXl0WjhKVDk1RWM2Y1Bj cm51NQpoaG0xcERqbjNrT3JZNlFvY211U0cvMy9URGErN2t5amwzSG5NOU5DYTBNU2NGT1lTU289 Cj1icTN2Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --==-=-=-- --=-=-= Content-Type: text/plain -------------------- End of forwarded message -------------------- --=-=-=--