From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) by sourceware.org (Postfix) with ESMTPS id E8EEB386F457; Wed, 15 Jul 2020 15:48:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E8EEB386F457 Received: by mail-io1-xd42.google.com with SMTP id c16so2704437ioi.9; Wed, 15 Jul 2020 08:48:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O09ixb7MUl2+mjIzih0ZG6E4CGXZDgECY2le4hMQ5/w=; b=eoIORYCmt1gC634d4SwGWQeSumdZ9htGF5ocUDvPO6cKZzEsm06j479VM+JfgpTpFE dRHqj7czJU1wF2QvcI9/Ki4Ot8HndBDDSRoKon6CohWD6/ouTXy9gFeG0ba31gsAPsFp O/klvkXfGRcZUp4wnd8y7nSxC8qANn08GdLUBzkdcPFTKU5DgCLg2P5k5ftcsWPBiil5 bPOWBBH5gGpHgmpzScFUhYJK9RcVCKLbK4ynjdrJkZ9ZtL0gxj9q+gzpZk96pQZXNZRE iRmkQMYGuekOwrnjVbL7DyOJ2cI2Q4u2xRAcJS4A72Wbc2Zb1y+ja5Akx5/OVFY28zvr RdVQ== X-Gm-Message-State: AOAM5339JtzaAdJ4GIVw8j8DXZ98vfm9p9uGdo8bb58DHP2hVYvV1SBX txRVYMVvrCWqmaUIVmKRoAixRL4vY47keLhhJik= X-Google-Smtp-Source: ABdhPJyoUsZTGNBj9BgnkJRasoMw4j+wFbHxSPK3bx/5SY0uSKrEQD/A7CNcRPOXy2efwVgJa5okV9zPZTGhgi4TcM4= X-Received: by 2002:a05:6638:1187:: with SMTP id f7mr47895jas.58.1594828096351; Wed, 15 Jul 2020 08:48:16 -0700 (PDT) MIME-Version: 1.0 References: <87tuyx4ijo.fsf@oldenburg2.str.redhat.com> <8a57b41ee8bbe9a8efbf3bb6d51d8c1548fc863a.camel@klomp.org> In-Reply-To: <8a57b41ee8bbe9a8efbf3bb6d51d8c1548fc863a.camel@klomp.org> From: "H.J. Lu" Date: Wed, 15 Jul 2020 08:47:40 -0700 Message-ID: Subject: Re: RFC: Add ET_DEBUG To: Mark Wielaard , GNU gABI gnu-gabi Cc: "H.J. Lu via Libc-alpha" , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gnu-gabi@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnu-gabi mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 15:48:18 -0000 On Wed, Jul 15, 2020 at 7:02 AM Mark Wielaard wrote: > > On Fri, 2020-06-26 at 23:35 +0200, Florian Weimer wrote: > > * H. J. Lu via Libc-alpha: > > > > > We need a way to identify "debug" info files, which appear like they > > > are ELF files but if inspected are actually missing a lot of > > > information and can't be properly parsed without the original DSO or > > > executable. > > > We propose > > > > > > #define ET_DEBUG 5 /* Debug information file */ > > > > > > Consumers should skip ET_DEBUG files if they don't know how to > > > handle them. Debuggers should process ET_DEBUG files to extract > > > debug info. > > > > I would like to see a change like this. > > > > For background: These separate debuginfo files contain the same program > > headers as the original object file, but all the loadable segments are > > missing from the file (including the dynamic segment). Tools compare > > these program headers for consistency, so we cannot change them in the > > separate debuginfo. > > > > In the dynamic loader, we only have ready access to the loadable > > segments. This means the ELF header is the only area of overlap, and > > the information to tell the two apart has to be located there. > > Note that this is only true for separate debug file for ET_EXEC and > ET_DYN ELF files. Some debug files, like stripped ET_REL ELF files, > split-dwarf .dwo files, supplementary debug files (dwz multi files), > don't contain any program headers. Should those also be marked ET_DEBUG > or not? I think they should. And then the above description should > simply say "may contain the same program headers as the associated > (original) object file...". > > Cheers, > https://gitlab.com/x86-psABIs/Linux-ABI/-/merge_requests/3 -- H.J.