Re: [PATCH RFC] backends: Add RISC-V object attribute printing
@Andreas: Can you take a look? Martin On 2/22/23 23:56, Mark Wielaard wrote: > Hi, > > On Fri, Nov 25, 2022 at 05:29:19PM +0100, Martin Liška wrote: >> On 10/13/22 16:53, Mark Wielaard wrote: >>> On Wed, 2022-08-10 at 11:27 +0200, Andreas Schwab via Elfutils-devel >>> wrote: This does not work yet. The RISC-V attribute tags use the same convention as the GNU attributes: odd numbered tags take a string value, even numbered ones an integer value, but print_attributes assumes the ARM numbering scheme by default for non-GNU attributes. >>> >>> Yeah, I see this comment in print_attributes: >>> >>> /* GNU style tags have either a uleb128 value, >>> when lowest bit is not set, or a string >>> when the lowest bit is set. >>> "compatibility" (32) is special. It has >>> both a string and a uleb128 value. For >>> non-gnu we assume 6 till 31 only take ints. >>> XXX see arm backend, do we need a separate >>> hook? */ >>> >>> Maybe we need a flag in the backend to tell whether attributes follow >>> the "gnu_vendor" convention? So that could be checked at: >>> >>> bool gnu_vendor = (q - name == sizeof "gnu" >>> && !memcmp (name, "gnu", sizeof "gnu")); >>> gnu_vendor |= ebl->has_gnu_attributes; >>> >>> Or something similar? >> >> Andreas: Can you please take a look at this? > > Has anybody had time to look at this? > > Thanks, > > Mark
Re: [PATCH v3] strip: keep .ctf section in stripped file
Hi Guillermo, On Thu, Feb 23, 2023 at 12:42:37PM -0600, Guillermo E. Martinez via Elfutils-devel wrote: > This is the third version of the patch to avoid remove the CTF section in > stripped files. Changes from v2: > > - Rebased from master. > > Please let me know your thoughts. > > CTF debug format was designed to be present in stripped files, so > this section should not be removed, so a new --remove-ctf option > is added to indicate explicitly that .ctf section will be stripped > out from binary file. Since the way to recognize a CTF section is by name ".ctf" does it really need a new option? eu-strip already has: --keep-section=SECTION Keep the named section. SECTION is an extended wildcard pattern. May be given more than once. -R, --remove-section=SECTION Remove the named section. SECTION is an extended wildcard pattern. May be given more than once. Only non-allocated sections can be removed. Do you really need a new option? Or could you use an explicit --keep-section=.ctf and/or --remove-section=.ctf ? Thanks, Mark
Re: [PATCH v3] strip: keep .ctf section in stripped file
On Fri, Feb 24, 2023 at 12:51:25PM +0100, Mark Wielaard wrote: > Hi Guillermo, > Hi Mark, > On Thu, Feb 23, 2023 at 12:42:37PM -0600, Guillermo E. Martinez via > Elfutils-devel wrote: > > This is the third version of the patch to avoid remove the CTF section in > > stripped files. Changes from v2: > > > > - Rebased from master. > > > > Please let me know your thoughts. > > > > CTF debug format was designed to be present in stripped files, so > > this section should not be removed, so a new --remove-ctf option > > is added to indicate explicitly that .ctf section will be stripped > > out from binary file. > > Since the way to recognize a CTF section is by name ".ctf" does it > really need a new option? eu-strip already has: > > --keep-section=SECTION Keep the named section. SECTION is an extended >wildcard pattern. May be given more than once. > > -R, --remove-section=SECTION Remove the named section. SECTION is an >extended wildcard pattern. May be given more than >once. Only non-allocated sections can be >removed. > > Do you really need a new option? Or could you use an explicit > --keep-section=.ctf and/or --remove-section=.ctf ? > Oh, I see, thanks for your comment!. My intention with this patch is to replicate the same proceeding by _default_ implemented in `binutils strip' tool, it is: not remove CTF section, except it is indicated explicitly. Of course, if you think it is not really a good idea, I can propose a patch to change the invocation of `eu-strip' in `find-debuginfo.sh' to preserve CTF section as you showed above, when it generates debug packages. Kinds regards, guyillermo
