PSARC/2007/509 elfedit

Ali Bahrami Ali.Bahrami at Sun.COM
Thu Sep 6 09:26:33 PDT 2007


James Carlson wrote:
> Ali Bahrami writes:
>> I am sponsoring the following fast track for myself - timeout 9/12/2007
> 
> Excellent new feature!  Just two questions:
> 
>> Internal Module interface			Private
> 
> What kind of "private" is that intended to be?  "Project Private"
> would prevent others from contributing modules, which might be
> appropriate if you're not sure you're ready to open the interface
> within ON.  "Consolidation Private" (the most likely case) would mean
> that others within ON can contribute modules without special review --
> likely no ARC review at all, as it seems you aren't planning on
> submitting those interfaces for ARC review -- but not outside ON.
> 
> Others are possible, but those seem like the two likely choices.
> 
>> 	-r-xr-xr-x   1 root  bin   159448 Sep  3 14:32 /usr/bin/amd64/elfedit*
>> 	-r-xr-xr-x   1 root  bin   124916 Sep  3 14:32 /usr/bin/elfedit*
> 
> Looking at the documentation, it seems that this utility is quite
> different from mdb in the way it handles bitted-ness.
> 
> Mdb looks at the target program and then launches the correct version
> (32-bit or 64-bit) as needed.  There's a tiny stub in /usr/bin that
> does this:
> 
> % ls -l /usr/bin/mdb /usr/bin/i86/mdb /usr/bin/amd64/mdb
> -r-xr-xr-x   2 root     bin       655528 Aug 28 12:57 /usr/bin/amd64/mdb
> -r-xr-xr-x   2 root     bin       511468 Aug 28 12:57 /usr/bin/i86/mdb
> -r-xr-xr-x  70 root     bin         9384 Aug 28 12:56 /usr/bin/mdb
> % 
> 
> Based on the man page, it seems that this program always runs as
> 64-bit if the platform supports 64-bit operation.  It does so
> apparently without regard to the target type.  Is that right?  Why
> does it do that?  Does it need to do that?
> 
> The man page describes behavior that's almost like the existing
> isaexec feature.  If that's what's needed here, then why doesn't it do
> that?
> 
> (My guess is that this is borrowing design from elfdump rather than
> from mdb.)
> 
> The documentation in the man page on this point seems strange:
> 
> USAGE
>       When supported by the system, elfedit runs as a 64-bit 
>       application, capable of processing files greater than 
>       or equal to 2 Gbytes (2^31 bytes).
> 
> That's strange because you don't need to have a 64-bit application in
> order to process large files.  That can't be the reason, can it?
> 

Consolidation Private. The overall goal is to open it up, so having it
open to ON is a reasonable first step. Anyone planning on using these
interfaces is warned to expect a little churn, but I've implemented
enough modules to have confidence that it is close to its final form.

---

You are correct that elfedit will go 64-bit immediately on any system
that can support it. This is like elfdump, and unlike mdb. Either version
of elfedit (32 or 64-bit binary) is able to edit either form of ELF object
(ELFCLASS32 or ELFCLASS64), so the reason to prefer 64-bit is for address
space and large file support.

It is true that a 32-bit program can process large files if built
to be large file aware. However, to the best of my knowledge, none of
the 32-bit linker tools are built that way. Instead, we always supply
full 64-bit versions of the programs.  Some large file aware programs
can be written to process data in chunks that fit in memory, but the
linker tools almost always want to map the entire object. This means that
any linker tool that needs to be large file aware probably also needs
large memory, which means it needs to be 64-bit.

There is a scenario in which a 32-bit elfedit, editing a very large
32-bit object might fail due to address space limits, while a 64-bit
elfedit would succeed. elfedit takes space in the process, on top of
which libelf needs room for the object, which may be mapped or otherwise
copied into memory. This is different than mdb, since mdb runs in its
own address space, and does not increase the address space of its target.

The mechanism used to handle this is in fact based on isaexec(). The
linker tools all use a common internal function named conv_check_native()
that examines the LD_NOEXEC_64 environment variable to decide what to
do, and then uses isaexec() to do the work. elfedit is following this
family pattern.

My plan is to stay with the current implementation for this, but I
am open to further discussion if you feel I've missed something.

- Ali



More information about the opensolaris-arc mailing list