doctor electron <[EMAIL PROTECTED]> writes:
> >You have not described any benefit beyond abstract appeals to what you
> >think object files should look like. That doesn't count. Give us a
> >measurable benefit and we'll consider it.
>
> I did: the vast amount of .obj files containing useful
> p
Long, long ago, Ian Lance Taylor, a life form in far off space,
emitted:
>We would discard the ABI in a second if the benefit exceeds the cost.
We agree; I'm happy.
>What benefit would we gain by changing the definition of R_386_PC32?
As stated, I don't know; the case was discussed as an exampl
doctor electron <[EMAIL PROTECTED]> writes:
> 2. As one who finds much in Linux to be very praiseworthy, I
> worry a bit about what seems to be such allegiance to a
> 20-year-old ABI doc which may be inconsistent with making
> quality improvements in the future. [No hardware maker would do
> such
Long, long ago, Ian Lance Taylor, a life form in far off space,
emitted:
>If you ignore the contents of the .o file, then how do you propose to
>handle the assembler code
>call foo + 16
>?
ADDENDUM:
Thanks again for this implied explanation, where apparently rel
reloc info is split in two par
Airr <[EMAIL PROTECTED]> writes:
> As of late yesterday evening, we've been able to get this to work by
> linking the .obj (PE/COFF) files with ld emitting a PE executable, and
> then using objcopy to convert to the final ELF executable.
Yes, that is the usual technique. Of course it only works
Long, long ago, Ian Lance Taylor, a life form in far off space,
emitted:
>If you ignore the contents of the .o file, then how do you propose to
>handle the assembler code
>call foo + 16
>?
Very good question. Thank you. Apparently the ABI assemblers
would put foo's address in the rel reloc
Long, long ago, Eric Botcazou, a life form in far off space,
emitted:
>> If so, the market will decide; is a corrected ld favored or not.
>
>It's already decided: your proposed change would break the ABI, hence break
>binary compatibility by definition.
The ABI states linkers cannot make -4 them
Ian Lance Taylor wrote:
Greetings, Ian, et all.
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 t
Long, long ago, Eric Botcazou, a life form in far off space,
emitted:
>neither you nor us can change it now
Thanks for your further thoughts -- and even bigger story!
The answer to that is pending; I hope we can edit ld to not
require -4 in those rel reloc locations in input files.
If so, the m
> The ABI states linkers cannot make -4 themselves, they have to
> read it from a file? Heck, let's break it!
Come on, be serious, the ABI gives the reloc's formula, which de facto
prescribes assembler's and linker's behaviour.
> I gave the current definition in my previous emails (the only
> v
doctor electron <[EMAIL PROTECTED]> 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
> If so, the market will decide; is a corrected ld favored or not.
It's already decided: your proposed change would break the ABI, hence break
binary compatibility by definition.
> That's the marvel. Why was this not corrected 20 years ago?
Because, if you really think about it, the current de
Long, long ago, Eric Botcazou, a life form in far off space,
emitted:
>Interesting. Then your next task is to convince the dumb guys at Sun too
>because their toolchain behaves exactly like the Linux toolchain...
Thanks for this info, Eric.
As you might see in Ian's thoughtful reply, I don't
> As you might see in Ian's thoughtful reply, I don't think he
> gets the point (maybe my failure to communicate well):
The latter, really, I'm afraid.
> Clearly, ld is using the correct formula; the issue is *where*
> it gets the constant -4. If it did not try to read this from
> the input file
> Knowledge of how microprocessors work (re adding the offset to
> eip) goes back the beginning of the very first microprocessors
> of any kind. This is why it is amazing that *both* compiler
> writers and linker writers in linux seem to be completely
> uninformed about how the processors they use
Long, long ago, Ian Lance Taylor, a life form in far off space,
emitted:
>the four bytes affected by R_386_PC32
Dear Ian, I think a single statement edit would fix ld re rel
relocs: The place where we read the "four bytes affected" now
is the equivalent of
x = [the four bytes] ...or... mov eax
doctor electron <[EMAIL PROTECTED]> writes:
> >> As author of the HotBasic compiler for Windows, in porting same
> >> to Linux, I find that ld does not properly link relative
> >> relocations (R_386_PC32) in correct elf32-i386 .o files.
> >
> >GNU ld is correct according to the ELF ABI Processor S
Long, long ago, Ian Lance Taylor, a life form in far off space,
emitted:
>doctor electron <[EMAIL PROTECTED]> writes:
>
>> As author of the HotBasic compiler for Windows, in porting same
>> to Linux, I find that ld does not properly link relative
>> relocations (R_386_PC32) in correct elf32-i386 .
doctor electron <[EMAIL PROTECTED]> writes:
> As author of the HotBasic compiler for Windows, in porting same
> to Linux, I find that ld does not properly link relative
> relocations (R_386_PC32) in correct elf32-i386 .o files.
GNU ld is correct according to the ELF ABI Processor Supplement for
i
Hi!
As author of the HotBasic compiler for Windows, in porting same
to Linux, I find that ld does not properly link relative
relocations (R_386_PC32) in correct elf32-i386 .o files.
In particular, after opcode E8h (call), ld inserts a relative
value which is 4 bytes too much, as if it did not tak
20 matches
Mail list logo
