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
Hi Nick,
Try checking out the latest binutils sources from the CVS repository. It
is possible that this bug has already been fixed.
I have tried it with the latest release 2.17 and the problem still remains.
If not, then please could you open an official bug report and include a
test case wh
I would like to localize symbols within an unlinked object file on AIX 5.1.
However it seems that the symbols doesn't really get localized by
examining 'nm' output:
test.cpp:
#include
#include
void foo()
{
printf("foo\n");
}
void bar()
{
printf("bar\n");
}
int main()
{
foo();
bar();
retur
--- Additional Comments From asl at math dot spbu dot ru 2006-06-24 12:15
---
Nick,
Now no assertions at all. Files look fine.
However, I don't have a complete build system & sources which the attached .o
files was taken from. So I don't know the results of linking.
I'll let you know
13 matches
Mail list logo
