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

[Xiaozhu Meng <xmeng@xxxxxxxxxxx>]

Great! Thanks!

On Wed, Feb 20, 2019 at 11:26 AM John Mellor-Crummey <johnmc@xxxxxxxx> wrote:
>
> 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
>
>