On 11/8/17 9:09 AM, Mark Wielaard wrote: > Hi Alex, > > On Wed, 2017-11-08 at 15:14 +0200, Alexander Kanavin wrote: >> On 11/07/2017 11:17 PM, Neal Gompa wrote: >> >>>> Thanks, this is the offending commit: >>>> >>>> https://github.com/rpm-software-management/rpm/commit/88989572fff1f31e0c4f972a6895585e4742ef4b >>>> >>>> Looks like they added sophisticated in-place processing/rewriting of the >>>> actual binary (that is not possible to switch off). And it fails in case of >>>> grub modules. >>>> >>>> We, on the other hand, only need to extract the list of debug source code >>>> files. Any hint on how to do that without the use of rpm/debugedit? Perhaps >>>> something from binutils/elfutils? >>> >>> This is the first time I'm hearing of this. Has anyone talked to Mark >>> Wielaard (CC'd to this email) about fixing this properly for you guys? >> >> We don't have any particular interest in debugedit though. It is only >> used as a crutch to extract the debug source locations. If readelf can >> do the same thing, we'll use that - please do understand that reporting >> issues upstream costs time, especially if upstream replies with >> NEEDINFO, WORKSFORME or WONTFIX type of thing, so we prioritize what's >> truly critical :) > > Even though I don't know much about openembedded I am interested in > your use case. And why it breaks. > > There are a couple of ways already to tweak what debugedit does. > We could maybe add another for your use case. > > So a couple of questions. > > - What exactly breaks currently when you let debugedit rewrite the > debuginfo source paths?
Alexander has more info then I do here, but I believe running it against grub modules breaks the modules. > - How do you invoke debugedit? Do you use the find-debuginfo.sh script? http://git.openembedded.org/openembedded-core/tree/meta/classes/package.bbclass Start at line 337. def splitdebuginfo(file, debugfile, debugsrcdir, sourcefile, d): The function is called by: splitdebuginfo(file, fpath, debugsrcdir, sourcefile, d) file is set to the next file to process. (We only process known elffiles.) debugsrcdir is usually set to "/usr/src/debug" sourcefile is usually set to "working dir"/debugsources.list But the main invocation is actually at 362: debugedit -i -l sourcefile file > - What do you use the debug source files list for if not for the actual > packaging? We used to use it to both munge the source file path as well as collection the sources to package. However, we no longer need the munging support, as we always build with the GCC options to setup the source file path for the proper target location. DEBUG_PREFIX_MAP ?= "-fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \ -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \ -fdebug-prefix-map=${STAGING_DIR_HOST}= \ " So essentially what we want is a simple read-only, give me a list of all of the referenced sources. > BTW. If you really don't want to use debugedit then you could use > something simple like a quick hack to list all sources I wrote some > time ago: > https://lists.fedorahosted.org/archives/list/elfutils-devel@lists.fedor > ahosted.org/message/VZP4G5N2ELYZEDAB3QYLXYHDGX4WMCUF/ > (see the dwarfsrcfiles.c attachement) This may very well do what we need. Our output does not depend on RPM (or any specific package manager.) We had simply been using the debugedit from RPM as it was the best tool for the job. Now that GCC has the debug-prefix-map option, we no longer really need debugedit. --Mark > Cheers, > > Mark > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core