[Rpm-maint] [rpm-software-management/rpm] debugedit: don't reorder sections (#565)

Sergei Trofimovich notifications at github.com
Mon Feb 25 19:46:45 UTC 2019


On Mon, 25 Feb 2019 01:19:30 -0800
rpm-maint <notifications at github.com> wrote:

> Hi,
> 
> On Fri, 2019-02-22 at 03:29 -0800, Panu Matilainen wrote:
> > FYI, I pinged the debugedit maintainer about this via email as he's
> > not on GH.  
> 
> I do get the emails from github throught he mailinglist. Although I
> admit to find them not very useful because they often omit the
> important bits of the discussion. But in this case I should certainly
> apologize for not replying earlier.
> 
> First, I am slightly surprised that debugedit did process the crt.o
> object file in the first place. Normally object files are not
> executable, so they aren't found by find-debuginfo.sh.
> 
> It should maybe be processed if it contains debuginfo that is kept and
> will be added to executables. 
> 
> But since it is an ET_REL object file it shouldn't have a build-id, so
> using -i is certainly wrong (using -n instead however doesn't fix the
> issue).
> 
> That the fix is to not reorder sections is slightly suspicious since
> section ordering doesn't matter for ET_REL object files. But it might
> certainly cause some unexpected/buggy behavior. I'll look into what is
> happening.
> 
> But it might be good to figure out how and why debugedit is called on
> this object file in the first place.

Gentoo runs 'debugedit' (process_elf helper) directly (without
find-debuginfo.sh call) on all files that look like ELF files here:
    https://github.com/gentoo/portage/blob/master/bin/estrip#L430

        f=$(file "${x}")
        ...
    	elif [[ ${f} == *"SB executable"* || ${f} == *"SB pie executable"* ||
		${f} == *"SB shared object"* ]] ; then
		process_elf "${x}" "${inode_link}" ${PORTAGE_STRIP_FLAGS}
	elif [[ ${f} == *"SB relocatable"* ]] ; then
		process_elf "${x}" "${inode_link}" ${SAFE_STRIP_FLAGS}
        fi

-- 

  Sergei


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/565#issuecomment-467155686
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20190225/a7f7c4f3/attachment.html>


More information about the Rpm-maint mailing list