Re: BUG elf32-i386 R_386_PC32 done wrong

[Ian Lance Taylor]

doctor electron <address@hidden> writes:

> As you might see in Ian's thoughtful reply, I don't think he
> gets the point (maybe my failure to communicate well):

I completely understood what you said.


> ld can get the -4 on its own, rather than read it from "typical"
> input files and thereby conform to the rel reloc formula *and*
> remove the requirement that .o files contain -4 at all those
> locations, which must be a continuing source of shame and
> embarrassment to writers of existing Linux compilers (nasm, C,
> etc).  Note that if ld coughs up its own -4 (per the formula I
> posted), all the existing .o/.so files would still link -- the
> -4 is a *constant* in the hardware-based formula and its
> presence in those .o/.so files should properly be ignored [so
> correct input files with any arbitrary value (e.g., 0) in those
> locations would also link].

If you ignore the contents of the .o file, then how do you propose to
handle the assembler code
    call foo + 16
?

With the ELF ABI as designed and implemented, it is easy.  This type
of code can arise when the compiler implements alternate entry points
for functions: one external to the file and one internal.


> Notice Ian gave no rationale beyond what I might call "This is
> the way we do it" and "Some ABI document covers us", as if any
> document changes how existing processors work.

We have an ABI so that all tools agree on the processing of i386 ELF
input files.  The ABI was written at AT&T, the designers of the ELF
format, back in 1990 when the ELF object file format was first
designed.  In order for tools to interoperate, they must all implement
the same ABI.  And they do.  And that ABI says that R_386_PC32 is
implemented by adding the offset from the address to the contents of
the four byte field.  There is no -4 in the formula.

Note that 1990, when these rules were laid down, was before the Linus
had even started working on the Linux kernel, and long before the
Linux kernel supported ELF (Linux originally used the a.out object
file format).  So when you describe this as a Linux issue, you just
sound ignorant of history.  There are several systems besides Linux
which implement the i386 ELF ABI, and .o files for those systems all
interoperate correctly.


> From what we see in this thread of posts, will they have nothing
> credible that makes any sense -- other than some ABI doc says
> it's OK?  The enquiring public will want more substance than
> that.

OK, now you're just being a troll.


> Why do Linux developers appear to want to keep correct .o files
> (no -4 constants in there) out of the Linux environment?  Is the
> intent to keep quality software out of the Linux environment?  
> The larger computing world outside Linux/Sun, etc, also has
> smart people producing useful object files -- in business, math,
> science, you name it.  But ld does not know how to link them!

If those object files are ELF, then ld knows how to link them.  If
they are not ELF, then ld follows the rules appropriate for the object
file format.


> What message are you sending?  

That we know how to follow published standards and interoperate with
other tools.


> Is the message that objcopy writers now must also go in and
> insert the -4's in .text sections when converting from .obj to
> .o?  All because ld can't find its own -4?  [Free gift, cut and
> paste any -4 in this post and put it in ld source code!] 

Is that the context of all this babble?  You want to convert from .obj
files, presumably in the Windows PE/COFF object file format, to object
files in the ELF file format?  If you want to do that conversion, then
subtracting 4 from the contents of the section for PC relative relocs
is the least of the issues you are going to have to deal with.

Or, if you have a compiler which generates PE/COFF and you want to
generate ELF, then just produce assembly code and feed it into an ELF
assembler.  The right thing will happen.

Ian