Nick Clifton <[EMAIL PROTECTED]> writes:
> Hi Dave,
>
> >I think there's a bug in the way objcopy handles R_386_32 (absolute
> > 32-bit) relocation entries when translating from elf to pe-i386
> > (windows) object files.
>
>
> > The symptom is that R_386_32 relocations in elf get translated
This turns out to be convenient in cases where one's build system
defaults to "ld --fatal-warning" but occasionally one would like to
override it. It's also parallel to existing gcc conventions for setting
and unsetting options. See attached diff to ld/lexsup.c; it's against
2.17 but patches
A kernel linked with gold fails early in the boot process during
the kernel image decompression (»bad gzip magic number«).
This happens an 64bit machines running 64bit kernels.
--
Summary: kernel image decompression fails on 64bit machines
(linked with gold)
--- Additional Comments From cryptooctoploid at gmail dot com 2008-05-30
17:51 ---
>I assume you are building a 64-bit kernel on the amd64 box?
Yes.
>Should we track this problem in a separate PR so it gets a unique ID?
Ok, I will enter a new bug.
--
http://sourceware.org/bugzill
Hi Dave,
Is this considered a bug, or a design compromise, in objcopy ?
Ie is it something that will get fixed if someone cares enough, or is
it not something that it was ever intended to do (and so a patch would
be rejected) ?
It is a design compromise. Translating relocs is a very difficult
--- Additional Comments From kris dot van dot hees at oracle dot com
2008-05-30 17:15 ---
That seems to be a quite different problem, because that message is typically
displayed during the uncompression of the linux kernel image very early on in
the boot process, which leads me to think
--- Additional Comments From cryptooctoploid at gmail dot com 2008-05-30
16:42 ---
The kernel still does not boot on my machine (amd64) using the current »gold«
version. It prints this message:
»bad gzip magic number«
So we got a step further, but are still not quite there.
I noticed t
--
What|Removed |Added
CC||andi at firstfloor dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=6407
--- You are receiving this
--- Additional Comments From nickc at redhat dot com 2008-05-30 16:15
---
Hi Frediano,
Well the patch makes sense - we are creating symbols for shared libraries, and
so the default ought to be to place the symbol in the dynamic symbol table
rather than the static symbol table. So I h
--- Additional Comments From drow at sources dot redhat dot com 2008-05-30
16:03 ---
Subject: Re: Handling of EF_FRV_PIC
On Wed, May 21, 2008 at 10:34:13AM -, nickc at redhat dot com wrote:
> I have uploaded a patch to this PR which I think might correct the
> linker's behaviour,
Hi Dave,
I think there's a bug in the way objcopy handles R_386_32 (absolute
32-bit) relocation entries when translating from elf to pe-i386
(windows) object files.
The symptom is that R_386_32 relocations in elf get translated into
DIR16 entries in the pe-i386. (Or perhaps just not trans
--- Additional Comments From nickc at redhat dot com 2008-05-30 15:38
---
Hi Eric, Hi Jevin,
Please could you try out the uploaded patch and let me know if it works for
you ? (I am especially interested to know if it works on the real programs
where you encountered this bug, not just
--- Additional Comments From nickc at redhat dot com 2008-05-30 15:37
---
Created an attachment (id=2768)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=2768&action=view)
Add test for no local symbols
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6019
--- You are re
--- Additional Comments From nickc at redhat dot com 2008-05-30 14:20
---
Hi Guys,
I have checked the patch in.
Cheers
Nick
gas/ChangeLog
PR 5523
* config/tc-avr.c (avr_ldi_expression): Do not warn about unknown
relocs here.
--
What|Remove
14 matches
Mail list logo
