Re: [DynInst_API:] elfutils, elf.h, and dyninst

[John Mellor-Crummey <johnmc@xxxxxxxx>]

Xiaozhu,

See the message below from Mark Wielaard regarding this issue. The plan was to provide an option to meet the need you identified.

--
John Mellor-Crummey Professor
Dept of Computer Science Rice University
email: johnmc@xxxxxxxx phone: 713-348-5179

From: Mark Wielaard <mjw@xxxxxxxxxx>

Subject: Re: Issue with elfutils and elf.h

Date: January 18, 2019 at 7:29:48 AM CST

To: "Mark W. Krentel" <krentel@xxxxxxxx>, Ben Coyote Woodard <woodard@xxxxxxxxxx>, John Mellor-Crummey <johnmc@xxxxxxxx>

Cc: Barton Miller <bart@xxxxxxxxxxx>

Hi,

On Sun, 2019-01-13 at 21:26 -0600, Mark W. Krentel wrote:

So, if you want elfutils to be more helpful, then add a config option
--enable-install-elfh that installs elf.h for the use cases that want
it.  Either that or it's easy to work around.  I just thought it made
sense to have elfutils install the file rather than have every package
that uses it to do something.

I finally changed my mind about this being a bad idea.
It really isn't so bad if, as you say, it is done with
a non-standard or private install.

I did make configure yell and scream if you use --enable-install-elfh
with a standard prefix though. Since that might override the
glibc/system elf.h, which would be bad.

Proposed patch is here:
https://sourceware.org/ml/elfutils-devel/2019-q1/msg00059.html

Thanks,

Mark

On Feb 20, 2019, at 11:14 AM, Xiaozhu Meng <xmeng@xxxxxxxxxxx> wrote:

Hi,

Sorry for digging deep for this old thread, but this issue actually is
deeper than originally expected.

On a recent linux distribution on x86-64, Dyninst failed to handle
relocation type: R_X86_64_REX_GOTPCRELX. I fixed Dyninst's handling of
this relocation type, but found that Dyninst cannot compile on a
relative old linux distribution, also on x86-64. On this old linux
distribution, relocation type R_X86_64_REX_GOTPCRELX is not defined in
the system "elf.h".

Note that this issue is beyond "rhel6 does not support aarch64". On
any architecture (regardless of x86-64, ppc, or aarch64), as long as a
new relocation type is introduced, the "elf.h" on older system of the
same architecture will miss relocation definitions.

We believe the best scenario for us is that elfutils installs "elf.h"
when a non-system install location is specified. Otherwise, I guess
then Dyninst can choose to copy and use the elf.h from the downloaded
source elfutils.

Thanks,

--Xiaozhu


On Sat, Dec 29, 2018 at 11:06 AM John Mellor-Crummey <johnmc@xxxxxxxx> wrote:

Dyninst folks,

Below see the advice from Mark Wielaard (elfutils lead) about dyninst and ARM on RHEL6.

--
John Mellor-Crummey

(sent from my phone)

Begin forwarded message:

From: Mark Wielaard <mjw@xxxxxxxxxx>
Date: December 29, 2018 at 10:51:20 AM CST
To: John Mellor-Crummey <johnmc@xxxxxxxx>
Cc: woodard@xxxxxxxxxx, "Mark W. Krentel" <krentel@xxxxxxxx>
Subject: Re: Issue with elfutils and elf.h

Hi,

On Fri, 2018-12-28 at 21:56 -0600, John Mellor-Crummey wrote:

See the email thread that discusses problems because elfutils doesnât

install elf.h.


elfutils explicitly doesn't install elf.h because it is a simple copy
from glibc and we don't want to conflict with it. The issue seems to be
that the glibc elf.h copy on RHEL6 doesn't support aarch64. Normally
this wouldn't be an issue since none of the aarch64 related constants
from elf.h are needed to use libelf.h or elfutils/libdw.h.

I am not sure what the correct approach is here. RHEL6 simply doesn't
support aarch64. So maybe to simplest approach is to not build aarch64
related code on targets like rhel6 which doesn't have a new enough
glibc?

Cheers,

Mark

_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api