Message ID | 20180522110019.3839-1-alan.hayward@arm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 21908 invoked by alias); 22 May 2018 11:00:57 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 21497 invoked by uid 89); 22 May 2018 11:00:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.0 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: EUR01-HE1-obe.outbound.protection.outlook.com Received: from mail-he1eur01on0044.outbound.protection.outlook.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (104.47.0.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 22 May 2018 11:00:32 +0000 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Alan.Hayward@arm.com; Received: from C02TF0U7HF1T.arm.com (217.140.96.140) by VI1PR0802MB2141.eurprd08.prod.outlook.com (2603:10a6:800:9b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.776.11; Tue, 22 May 2018 11:00:28 +0000 From: Alan Hayward <alan.hayward@arm.com> To: gdb-patches@sourceware.org Cc: nd@arm.com, Alan Hayward <alan.hayward@arm.com> Subject: [PATCH] Use ELF_SECTION_IN_SEGMENT to map segments Date: Tue, 22 May 2018 12:00:19 +0100 Message-Id: <20180522110019.3839-1-alan.hayward@arm.com> MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: CWLP265CA0024.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:10::36) To VI1PR0802MB2141.eurprd08.prod.outlook.com (2603:10a6:800:9b::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0802MB2141; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0802MB2141; 3:J8zrQivhYBtKq7OynQcIJyuUKc5kK6ZJB4Fs6VeVP3OVilE0EtAZU5KDGyZs3shpox/I23Wio8gpmZDz5CwovqOCgjvGH0Phid1GonozLUezLLjZf1TImMNVyNROoGmvWTzpb96Pg8dfjnrx4PUfLVo5iC/7y4PqdVEGgVTZtacnKZRaIL5QzmyWBRr3RX+Ml9a0pareul8mXVpJ9Et0LgMKpVRf/dqn5swsklVspa5c14M1FB1iTHQhG5cWDMUr; 25:b997N5V6CkSNZsuA+FsRegJyPTvEW2B3Zxj+sOHL4wl2HApnlEJRPaoZ6/eZDnn74HnIURzQpdBzkjM52+0GpYXT/2NsAAzX/iaIzwvfxv82AiRKk9MZokALBMyVEyy/mN615BuCnDVgyyi5I3C80pZwW1N+EyXuzQLPfPc7nuw9RbhHvtEVmS+/8zFrZhmXS15ZoF73Bc/K85NGKPVlbhKTzjyrEwgMGk4ejIVLfx1C81W+kMh/MOcja33DCcGNhoszU4X7U4SPUbpv89v1jbFajTeN178LUoPMgZJBmzGk+09iFiHk7t4o1MoEEsxn6O6Ka9e0yXvzuW3fiwQtpQ==; 31:BzP633UPAZTBXXfNwhkL1uCJNAO6YwokFA3rhIsL9u6YSZRtENcfCKYyiVzSvQg/nogQwczCFAOFuSFlehtS3dg9uEBsYX+M7EZupuqF+QbzRKDIIM6Mpslr6IV0PiG28KqyKeIMG3dP4k1rHqdKLRMcLoCfdSAyRd4w82CYL7aorhOpHOUU5hm9dq+S9RNNom49ntt43/G7KuOVOuD1opeIcDivqoFhyAsJ80Arh3Y= X-MS-TrafficTypeDiagnostic: VI1PR0802MB2141: NoDisclaimer: True X-Microsoft-Exchange-Diagnostics: 1; VI1PR0802MB2141; 20:pKLxQIyHbu8UVC/qJnRwG/AFYhfcth+ljH0tgKo7Dc/HLKWYUPQytvHdCa/nTC9MRcxeKLJ/MOenfcGCKWq42rBeYx43XBaWHdKZCkdKmLJheTb29VaG7BPJ3PlxNCCBaOBcynWfTJcEXkziSGUDfiIbfGVNJsUSKe1LUV5Gpg/zoCnU72nJrI6gTmwJTF7uTPDx2NDBAcsXR2HrA9EI39Wu3RovpxPKar5brjuZ3ZSAiSMEhlJzKqLV/nhAaj80; 4:wHs2ziSAjPbsBCUYXgkxxLgbm8TNV4uNHTF92qA1nY88uowE274mwr2oqdsMqwD+VN05ykaqxw55ns6kYHFk9GnhkMJXAIaTVehvyPZ6Gs1GhNmmLox2YdomOSSlCrN7Y6HR3UUQgy58Qcbp53AuLhc/FSI9V6ujbNBx9ckrxrxGp96rqQXmE63WJdHA8bQEbeM6Q/qWrY+o+w47to7x+wKOhXvG+JvLE/3NjMyuVVZcLJsCEHRqJDB0sI4Bq896uDsFcqwqFOAoP0BXgQxBk3apzCnn3krguMyDbCBGD8R/gDBNUbdu4fWhcNmZZUHK X-Microsoft-Antispam-PRVS: <VI1PR0802MB214109F56302A867C7558CD297940@VI1PR0802MB2141.eurprd08.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:(180628864354917); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0802MB2141; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0802MB2141; X-Forefront-PRVS: 0680FADD48 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(366004)(346002)(376002)(396003)(377424004)(189003)(199004)(476003)(2616005)(486006)(25786009)(8936002)(316002)(956004)(68736007)(72206003)(2351001)(8676002)(81156014)(16526019)(3846002)(186003)(50226002)(81166006)(48376002)(2361001)(105586002)(50466002)(478600001)(1857600001)(53416004)(6486002)(106356001)(16586007)(47776003)(44832011)(66066001)(6916009)(6666003)(36756003)(4326008)(305945005)(86362001)(7696005)(386003)(26005)(2906002)(6116002)(5660300001)(1076002)(53936002)(52116002)(51416003)(97736004)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0802MB2141; H:C02TF0U7HF1T.arm.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR0802MB2141; 23:HuSHDKZMDioKRUjeB/2Foq/OLsVIjbybXdTslG/?= =?us-ascii?Q?QeDHn3n/in+QTi/x3/xkyHXvxnJkk/azl6ELs5o9rt7MrUB10cVnQt9HXcun?= =?us-ascii?Q?SnI1BPD8Gfy0i1xW+odcYY/a6WWF8R4JSXrPlbv0hX2xSoR9XDUpMvFMiSGE?= =?us-ascii?Q?j7rFeWUju3FCdmQUp7U6r8jxkDkB26xXEEia3SFxvep4U8UbvX0GjhDoOcRB?= =?us-ascii?Q?dlfvXmWfccve5oovUn0u22o3AU/MtGO6vzPyviYibLegiaBhh+8y/RaltT61?= =?us-ascii?Q?8Ttj0WubHWNwRq682bVukcUN9pIsENOF6bdFfIb5dcB/sgpfTu5iKYjgSFch?= =?us-ascii?Q?mSh8211HKAJeCraJXWk4x4f9BpNIs4yyzmgGN/8YyK2OGsZcfDTiq7UZ+Cny?= =?us-ascii?Q?P8Qx7IYRFi0UJJkzD7Ak2uMV7NTYONgfA6t+PdMiKGxHguzReltENI5+dzsQ?= =?us-ascii?Q?NFqAlPkn+JVvgWW9F+I8jWQzyRq3IoKBdg+xHDP8pxXPjY4cZZJJnm9xjdrW?= =?us-ascii?Q?U0C6E5F+etW/xplFJfuQUoJDkFA1YvDSNW1TD2iVZLa4VN5nWb3apJFuL86q?= =?us-ascii?Q?B70vilSOe/MT+3m9TRHvlMiMh2v0a7Ueihs7w7t8qxWK6C25wYGSSBRrIui2?= =?us-ascii?Q?1YzddUHrPf5noQaKytsly8jH/DZMjPahar1akR7Ad6E8yU0cGYsDmm+sOY6M?= =?us-ascii?Q?5ywXqMSsP67akoE4kL/7GKw0V+2v6RPDWI+KmoPB7wbVmf8ljMbO87hG6yUg?= =?us-ascii?Q?1X0GPEdxbpbdHLHXOzObJz7CEId8uQDxz/bgjkgRDZWwqbWw2HHQ0qkgZ6xo?= =?us-ascii?Q?02CU0yRmV+213EH1pedyFOFsfmxFWXW8pndpJ5uPgAvIrbg2MhKz1pgdAguz?= =?us-ascii?Q?H5janTi1Z9j4U5HMTXKhxiOxxLqnlyPMoL8w0h6eaPFnZ0hEI9tcYSM+22aD?= =?us-ascii?Q?a0i7jBuOcXnxeG2w5I3LcMUF+3NPa+LECpfe8WS//3kU+jlCgZat/Tc5xHLU?= =?us-ascii?Q?3U5WdAUtwLP+H8bXHiMv9eZu6ZK+zbtxHNY0tGYFqUPfTN0RQJiuQ5XHoAix?= =?us-ascii?Q?Yg/R4MSII2rZe8MH4EjoazPDgekn3vVZfovDL9m/eoPNndMOIKeBW/HxmiUH?= =?us-ascii?Q?TNbIDQ+aBnlv09wv15H07w/e+J9xlOvjwg0RSkUDaQzNnhmoN2uIQSVcqcu3?= =?us-ascii?Q?pNppdESxOTsKmcF03UtpzZNnk3eFw5ck9vKTt0euMVLuXd9a9YgRS7E+o5ae?= =?us-ascii?Q?75wKjeUMQ4hXOjB32xU6WTbQ8NGjLWtGma3nyvS9G?= X-Microsoft-Antispam-Message-Info: 5nRO4lb79WPRogE19nlrVPr13ImFIBv9hZAg5CIiC+GOgHR5dpD115hrHUgkLqRDv0GjqaOLQKMtP1p+4a10WW7DXOaxmlXgs9GZDMuOVhKEo0TsiZhZz2CWyD9TildfJ8Szw0w+ME2BGaikYdGZJ+Qfg+UTbJYUXmwAzJw6TtOrv+/uHlJzZVVf3HjadoL1 X-Microsoft-Exchange-Diagnostics: 1; VI1PR0802MB2141; 6:cn89eqgnuh+/29ZgWmt43USgYoue1LKfBhdo8jQLoiQMs/rH/+VMJWBS7SX3zQjLKs7ivpoy9o9xZ2QR2/4/tfhCmax0TJ1+cWLV5/Jod3z6X9pwa+fCLOwXlpumBxuQn9cSAWgHiAhSkHmJP3Xpw+O9k2dXRh7W2C33/3F0ezl44xTteuStg4WF4LhUGd2NHUEscwTDIFU38BTXw7p57A4cQarvk59wdMZbrY+gUY9eoxQNgfzkBKx0vIg4UffzNQJyS1ElyjPn8Y/050sSqmjCo8o0BL1arnFBf4YUCH1yh9YpVqW8lxk2C8hvcEBgzi9UlaB7h3KbWQr4h0hlAC5RtmA7hUsAf+GK74CdQIsZpca5qQFAhrRcf+1p3t+f0ORzKC5AA+JCFAcmx/gl9ZGZsPQkUuMbi4tIbVlVNEXzJn3xEzEfMJhyY5lFmDh1NZzUObTwGoeXBX+Zj6Df7Q==; 5:+o0tgxlgJm1HnEy5/vMy2xU9hyOpKNt6Fla8O7mD9HBPpel+U0GSLIwC1YtrTGcusniTzPV+Q/oYmzRPlpRn5ysNWSvDsN0ouzZuaeq5FUsGSG9BDvedMssWsOIj8wRTZ7tMZohB4T7JzYbUAouGdvRFMiOSjQQ7dzIxV3Kxbqs=; 24:i+YYXmuMCZC3NZnjikwskVl5SuwfKVcjKmGGiFkSTjhBdelHLIi6WW7M3ydVCYwcJW42oRYgu9D1JC1wHtnNpALGsOuhwTWLNOxFNE7QYJ8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0802MB2141; 7:HREQgZPdgobFN7Fc/R44P/tW3jb384qktl+sU/OFZB//wHvBiBguIqR/aVRhekxK9sMwVNCZQKEyUzutFqh5ARGqhBYrSmBdnceRHgNSlHpdmpPBQrJqxVx8Grddky4Qm1rMboCWrff68B4FQQ0qQ/bZZobLwVs3jRvaEHjsRx4UJZuE+XTwuYnKjZtZ3wG1bd95PBawf6RHnrIu3GfbicXSsiRotUt6guU1ZDJXNP4kCjHk0pXA/CxPOeQ7JRsn X-MS-Office365-Filtering-Correlation-Id: b5f02f77-d236-496d-5d9c-08d5bfd33aa9 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2018 11:00:28.2382 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b5f02f77-d236-496d-5d9c-08d5bfd33aa9 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2141 X-IsSubscribed: yes |
Commit Message
Alan Hayward
May 22, 2018, 11 a.m. UTC
The macro ELF_SECTION_IN_SEGMENT should be used when calculating if a section maps to a segment. The binutils patch "[PATCH] Use offsets instead of addresses in ELF_SECTION_IN_SEGMENT" makes further improvements to the macro. When the two patches are combined, this will allow GDB to be used to debug Arm baremetal binaries produced by the Arm Compiler. See the binutils patch for further details. Regardless of Arm debugging, this patch reduces code/logic duplication in gdb. This change has been tested using make check x86 on a binutils+gdb build. It has also been manually tested by using gdb to debug a Arm Mbed board. Alan. 2018-05-22 Alan Hayward <alan.hayward@arm.com> * elfread.c (elf_symfile_segments): Use ELF_SECTION_IN_SEGMENT. --- gdb/elfread.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
Comments
On 05/22/2018 12:00 PM, Alan Hayward wrote: > The macro ELF_SECTION_IN_SEGMENT should be used when calculating if > a section maps to a segment. > > The binutils patch "[PATCH] Use offsets instead of addresses in > ELF_SECTION_IN_SEGMENT" makes further improvements to the macro. > When the two patches are combined, this will allow GDB to be used > to debug Arm baremetal binaries produced by the Arm Compiler. See > the binutils patch for further details. > > Regardless of Arm debugging, this patch reduces code/logic duplication > in gdb. Sounds reasonable. > --- a/gdb/elfread.c > +++ b/gdb/elfread.c > @@ -120,17 +120,13 @@ elf_symfile_segments (bfd *abfd) > for (i = 0, sect = abfd->sections; sect != NULL; i++, sect = sect->next) > { > int j; > - CORE_ADDR vma; > + Elf_Internal_Shdr *this_hdr = &(elf_section_data (sect)->this_hdr); Drop unnecessary parens. You could defer this call until after the SEC_ALLOC check. > > if ((bfd_get_section_flags (abfd, sect) & SEC_ALLOC) == 0) > continue; > > - vma = bfd_get_section_vma (abfd, sect); > - > for (j = 0; j < num_segments; j++) > - if (segments[j]->p_memsz > 0 > - && vma >= segments[j]->p_vaddr > - && (vma - segments[j]->p_vaddr) < segments[j]->p_memsz) > + if ELF_SECTION_IN_SEGMENT (this_hdr, segments[j]) That is some odd-looking C/C++ code, for assuming the macro's internals are wrapped in parens. Please write the more usual: if (ELF_SECTION_IN_SEGMENT (this_hdr, segments[j])) OK with those fixed. Thanks, Pedro Alves
Thanks for the review. > On 22 May 2018, at 14:46, Pedro Alves <palves@redhat.com> wrote: > > On 05/22/2018 12:00 PM, Alan Hayward wrote: >> The macro ELF_SECTION_IN_SEGMENT should be used when calculating if >> a section maps to a segment. >> >> The binutils patch "[PATCH] Use offsets instead of addresses in >> ELF_SECTION_IN_SEGMENT" makes further improvements to the macro. >> When the two patches are combined, this will allow GDB to be used >> to debug Arm baremetal binaries produced by the Arm Compiler. See >> the binutils patch for further details. >> >> Regardless of Arm debugging, this patch reduces code/logic duplication >> in gdb. > > Sounds reasonable. > >> --- a/gdb/elfread.c >> +++ b/gdb/elfread.c >> @@ -120,17 +120,13 @@ elf_symfile_segments (bfd *abfd) >> for (i = 0, sect = abfd->sections; sect != NULL; i++, sect = sect->next) >> { >> int j; >> - CORE_ADDR vma; >> + Elf_Internal_Shdr *this_hdr = &(elf_section_data (sect)->this_hdr); > > Drop unnecessary parens. > > You could defer this call until after the SEC_ALLOC check. Ok. > >> >> if ((bfd_get_section_flags (abfd, sect) & SEC_ALLOC) == 0) >> continue; >> >> - vma = bfd_get_section_vma (abfd, sect); >> - >> for (j = 0; j < num_segments; j++) >> - if (segments[j]->p_memsz > 0 >> - && vma >= segments[j]->p_vaddr >> - && (vma - segments[j]->p_vaddr) < segments[j]->p_memsz) >> + if ELF_SECTION_IN_SEGMENT (this_hdr, segments[j]) > > That is some odd-looking C/C++ code, for assuming the macro's > internals are wrapped in parens. Please write the more usual: > > if (ELF_SECTION_IN_SEGMENT (this_hdr, segments[j])) Not quite sure why I didn’t spot that when writing it. > > OK with those fixed. > I’ll wait until the BFD patch has been approved before I push, as there is a small chance that review will cause me to make further changes. Will post again if I do. Alan.
Pushed this with changes as suggested. The BFD patch hasn’t progressed yet (possible extra changes needed elsewhere). Regardless, this patch can stand on it’s own. Alan. > On 23 May 2018, at 11:36, Alan Hayward <Alan.Hayward@arm.com> wrote: > > > Thanks for the review. > >> On 22 May 2018, at 14:46, Pedro Alves <palves@redhat.com> wrote: >> >> On 05/22/2018 12:00 PM, Alan Hayward wrote: >>> The macro ELF_SECTION_IN_SEGMENT should be used when calculating if >>> a section maps to a segment. >>> >>> The binutils patch "[PATCH] Use offsets instead of addresses in >>> ELF_SECTION_IN_SEGMENT" makes further improvements to the macro. >>> When the two patches are combined, this will allow GDB to be used >>> to debug Arm baremetal binaries produced by the Arm Compiler. See >>> the binutils patch for further details. >>> >>> Regardless of Arm debugging, this patch reduces code/logic duplication >>> in gdb. >> >> Sounds reasonable. >> >>> --- a/gdb/elfread.c >>> +++ b/gdb/elfread.c >>> @@ -120,17 +120,13 @@ elf_symfile_segments (bfd *abfd) >>> for (i = 0, sect = abfd->sections; sect != NULL; i++, sect = sect->next) >>> { >>> int j; >>> - CORE_ADDR vma; >>> + Elf_Internal_Shdr *this_hdr = &(elf_section_data (sect)->this_hdr); >> >> Drop unnecessary parens. >> >> You could defer this call until after the SEC_ALLOC check. > > Ok. > >> >>> >>> if ((bfd_get_section_flags (abfd, sect) & SEC_ALLOC) == 0) >>> continue; >>> >>> - vma = bfd_get_section_vma (abfd, sect); >>> - >>> for (j = 0; j < num_segments; j++) >>> - if (segments[j]->p_memsz > 0 >>> - && vma >= segments[j]->p_vaddr >>> - && (vma - segments[j]->p_vaddr) < segments[j]->p_memsz) >>> + if ELF_SECTION_IN_SEGMENT (this_hdr, segments[j]) >> >> That is some odd-looking C/C++ code, for assuming the macro's >> internals are wrapped in parens. Please write the more usual: >> >> if (ELF_SECTION_IN_SEGMENT (this_hdr, segments[j])) > > Not quite sure why I didn’t spot that when writing it. > > >> >> OK with those fixed. >> > > I’ll wait until the BFD patch has been approved before I push, as there > is a small chance that review will cause me to make further changes. Will > post again if I do. > > > Alan.
diff --git a/gdb/elfread.c b/gdb/elfread.c index b4b4a1b24c..3cf9b1ec21 100644 --- a/gdb/elfread.c +++ b/gdb/elfread.c @@ -120,17 +120,13 @@ elf_symfile_segments (bfd *abfd) for (i = 0, sect = abfd->sections; sect != NULL; i++, sect = sect->next) { int j; - CORE_ADDR vma; + Elf_Internal_Shdr *this_hdr = &(elf_section_data (sect)->this_hdr); if ((bfd_get_section_flags (abfd, sect) & SEC_ALLOC) == 0) continue; - vma = bfd_get_section_vma (abfd, sect); - for (j = 0; j < num_segments; j++) - if (segments[j]->p_memsz > 0 - && vma >= segments[j]->p_vaddr - && (vma - segments[j]->p_vaddr) < segments[j]->p_memsz) + if ELF_SECTION_IN_SEGMENT (this_hdr, segments[j]) { data->segment_info[i] = j + 1; break;