--- 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
--- 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=2768action=view)
Add test for no local symbols
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6019
--- You are
--- 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
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
--- 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,
--- 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
--
What|Removed |Added
CC||andi at firstfloor dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=6407
--- You are receiving
--- 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
--- 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
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
--- 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.
--
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)
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
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 into
DIR16
14 matches
Mail list logo
