[Bug ld/5785] Spurious "section xxx overlaps section yyy"
--- Additional Comments From nickc at redhat dot com 2008-02-22 11:27 --- Created an attachment (id=2287) --> (http://sourceware.org/bugzilla/attachment.cgi?id=2287&action=view) Respect the AT> syntax even if no other memory region for the section has been specified -- http://sourceware.org/bugzilla/show_bug.cgi?id=5785 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/5785] New: Spurious "section xxx overlaps section yyy"
Hi Sergei,
LD version 2.18.x produces bogus "section .xxx overlaps section .bss", while LD
version 2.16.1 works just fine.
Well the 2.18 linker is behaving as documented. Specifically in the bit
on the "Output Section LMA" in the manual:
If neither AT nor AT> is specified for an allocatable section,
the linker will set the LMA such that the difference between
VMA and LMA for the section is the same as the preceding output
section in the same region.
Since the .bss section does not have an AT or an AT> directive its LMA
is set to 0x110, so that difference between its VMA (0x4110), as set by
the "> RAM" directive, and its LMA is 0x4000, ie the same as the
difference between the VMA and the LMA of the .data section. (Try
running the linker with the --no-check-sections option and then looking
at the section headers to see this).
This is a change in the linker's behaviour that was made for the 2.18
release. There is even a mention of it in the NEWS file.
It does suggest a workaround for the problem: Change the "> RAM" in the
description of the .bss section to "AT> RAM". ie:
.bss : {
. += 0x120;
} AT> RAM
According to the manual this will set both the LMA and the VMA for the
section, and you will end up with the same behaviour as the 2.16 linker.
(This change is backwards compatible, i.e. it will work with the 2.16
linker as well). Unfortunately there is a bug in the current linker
sources such that the "AT> [region-name]" syntax is ignored unless there
is also an "> [region-name-2]" specified for the section, and the two
regions are different. I can see no good reason for this, and the
behaviour certainly isn't documented, so I am planning to check in the
uploaded patch to remove this restriction unless my regression testing
shows up a problem.
Cheers
Nick
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5785] Spurious "section xxx overlaps section yyy"
--- Additional Comments From nickc at redhat dot com 2008-02-22 11:29
---
Subject: Re: New: Spurious "section xxx overlaps section yyy"
Hi Sergei,
> LD version 2.18.x produces bogus "section .xxx overlaps section .bss", while
> LD
> version 2.16.1 works just fine.
Well the 2.18 linker is behaving as documented. Specifically in the bit
on the "Output Section LMA" in the manual:
If neither AT nor AT> is specified for an allocatable section,
the linker will set the LMA such that the difference between
VMA and LMA for the section is the same as the preceding output
section in the same region.
Since the .bss section does not have an AT or an AT> directive its LMA
is set to 0x110, so that difference between its VMA (0x4110), as set by
the "> RAM" directive, and its LMA is 0x4000, ie the same as the
difference between the VMA and the LMA of the .data section. (Try
running the linker with the --no-check-sections option and then looking
at the section headers to see this).
This is a change in the linker's behaviour that was made for the 2.18
release. There is even a mention of it in the NEWS file.
It does suggest a workaround for the problem: Change the "> RAM" in the
description of the .bss section to "AT> RAM". ie:
.bss : {
. += 0x120;
} AT> RAM
According to the manual this will set both the LMA and the VMA for the
section, and you will end up with the same behaviour as the 2.16 linker.
(This change is backwards compatible, i.e. it will work with the 2.16
linker as well). Unfortunately there is a bug in the current linker
sources such that the "AT> [region-name]" syntax is ignored unless there
is also an "> [region-name-2]" specified for the section, and the two
regions are different. I can see no good reason for this, and the
behaviour certainly isn't documented, so I am planning to check in the
uploaded patch to remove this restriction unless my regression testing
shows up a problem.
Cheers
Nick
--
http://sourceware.org/bugzilla/show_bug.cgi?id=5785
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4907] readelf doesn't dump .eh_frame_hdr section
--- Additional Comments From vda dot linux at googlemail dot com 2008-02-22 13:30 --- Created an attachment (id=2288) --> (http://sourceware.org/bugzilla/attachment.cgi?id=2288&action=view) First stab at dumping .eh_frame[_hdr] sections With this patch dumping "head" from coreutils (readelf -all -w head) looks like this: Exception information header section '.eh_frame_hdr' Addr: 0x0804d850 Offset: 0x005850 Version: 1 eh_frame_ptr: 0x28 Binary search table of 0x4 elements: 0: 0xea20 0x44 1: 0xeb78 0x64 2: 0xed04 0x84 3: 0xee10 0xa4 Exception information section '.eh_frame' Addr: 0x0804d87c Offset: 0x00587c CFI 0: Length: 0x0014 - CIE: Version: 1 Augmentation string: 'zR' Code Alignment Factor: 0x1 Data Alignment Factor: 0xfffc Augmentation Data (8 bytes): 0x01 0x1b 0x0c 0x04 0x04 0x88 0x01 0x00 Length: 0x001c - FDE 0: CIE ptr: 0x001c Length: 0x001c - FDE 1: CIE ptr: 0x003c Length: 0x001c - FDE 2: CIE ptr: 0x005c Length: 0x001c - FDE 3: CIE ptr: 0x007c -- http://sourceware.org/bugzilla/show_bug.cgi?id=4907 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5785] Spurious "section xxx overlaps section yyy"
--- Additional Comments From nickc at redhat dot com 2008-02-22 14:20 --- Patch checked in with this changelog entry. ld/ChangeLog 2008-02-22 Nick Clifton <[EMAIL PROTECTED]> PR ld/5785 * ldlang.c (lang_size_sections_1): Honour the setting of an lma_region even if there is no vma region set, or the vma region is the same as the lma region. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=5785 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/3134] objdump incompletely decodes mov disp:32 instruction
--- Additional Comments From vda dot linux at googlemail dot com
2008-02-22 15:04 ---
According to the .pdf, MOV.L ERs,@(d:32,ERd) instruction has this encoding:
[01] [00] [78] [0erd 0] [6B] [A 0ers] [disp:32]
or
[01] [00] [78] [1erd 0] [6B] [A 0ers] [disp:32]
where "[]" are bytes (or bigger: disp is 4 bytes).
I think it corresponds to this line in include/opcode/h8300.h:
{O (O_MOV, SL), AV_H8H, 6, "mov.l", {{DISP32SRC, RD32, E}},
{{PREFIX_0100, 0x7, 0x8, B30 | DISPREG, 0x0, 0x6, 0xb, 0x2, RD32, SRC |
DISP32LIST, E}}},
"PREFIX_0100, 0x7, 0x8, B30 | DISPREG..." part directly corresponds to
"[01] [00] [78] [0erd 0]"
B30 constant seems to mean "bit 3 in the nibble must be low":
B30 = 0x2000, /* Bit 3 must be low. */
So, just removing it (replacing "B30 | DISPREG" by "DISPREG" in that line)
should do the trick. Markus, can you try it?
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3134
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/868] bfd leaks memory in several places
--- Additional Comments From nickc at redhat dot com 2008-02-22 15:26 --- Hi Diogo, I have just realised that my dwarf2.c patch was completely bogus. There is no memory leak because the routines are using bfd_alloc and bfd_zalloc, which uses an objstack. The memory is freed later on in the linking process when bfd_release() is called. So I am going to revert my patch. Sorry about not realising this sooner. Cheers Nick -- http://sourceware.org/bugzilla/show_bug.cgi?id=868 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/3134] objdump incompletely decodes mov disp:32 instruction
--- Additional Comments From markus+sw at gyger dot org 2008-02-22 17:41
---
Close -- 18 lines up removing B31 works. Thanks, Denis!
--- binutils-2.16.1/include/opcode/h8300.h.orig Thu Mar 3 11:58:09 2005
+++ binutils-2.16.1/include/opcode/h8300.h Fri Feb 22 17:31:04 2008
@@ -1518,7 +1518,7 @@ struct h8_opcode h8_opcodes[] =
{O (O_MOV, SL), AV_H8SX, 0, "mov.l", {{RS32, DISP2DST, E}}, {{PREFIX_010,
B30 | B20 | DISP2DST, 0x6, 0x9, B31 | DSTDISPREG, RS32, E}}},
{O (O_MOV, SL), AV_H8H, 6, "mov.l", {{RS32, DISP16DST, E}}, {{PREFIX_0100,
0x6, 0xf, B31 | DSTDISPREG, RS32, DSTDISP16LIST, E}}},
{O (O_MOV, SL), AV_H8SX, 6, "mov.l", {{RS32, DISP32DST, E}}, {{0x7, 0x8, B31
| DSTDISPREG, 0x0, 0x6, 0xb, 0xa, RS32, DSTDISP32LIST, E}}},
- {O (O_MOV, SL), AV_H8H, 6, "mov.l", {{RS32, DISP32DST, E}}, {{PREFIX_0100,
0x7, 0x8, B31 | DSTDISPREG, 0x0, 0x6, 0xb, 0xa,
RS32, DSTDISP32LIST, E}}},
+ {O (O_MOV, SL), AV_H8H, 6, "mov.l", {{RS32, DISP32DST, E}}, {{PREFIX_0100,
0x7, 0x8, DSTDISPREG, 0x0, 0x6, 0xb, 0xa,
RS32, DSTDISP32LIST, E}}},
{O (O_MOV, SL), AV_H8SX, 0, "mov.l", {{RS32, INDEXB16D, E}}, {{PREFIX_0101,
0x6, 0xf, B31 | DSTDISPREG, RS32, DSTDISP16LIST, E}}},
{O (O_MOV, SL), AV_H8SX, 0, "mov.l", {{RS32, INDEXW16D, E}}, {{PREFIX_0102,
0x6, 0xf, B31 | DSTDISPREG, RS32, DSTDISP16LIST, E}}},
{O (O_MOV, SL), AV_H8SX, 0, "mov.l", {{RS32, INDEXL16D, E}}, {{PREFIX_0103,
0x6, 0xf, B31 | DSTDISPREG, RS32, DSTDISP16LIST, E}}},
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3134
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/5785] New: Spurious "section xxx overlaps section yyy"
Hi Nick,
Thank you very much for taking care of the issue, and please take easy
what I write below, -- this is a woe of a guy who feels very unlucky as
every upgrade of binutils breaks his linker scripts.
Nick Clifton <[EMAIL PROTECTED]> writes:
> Hi Sergei,
>
>> LD version 2.18.x produces bogus "section .xxx overlaps section .bss", while
>> LD
>> version 2.16.1 works just fine.
>
> Well the 2.18 linker is behaving as documented. Specifically in the
> bit on the "Output Section LMA" in the manual:
>
> If neither AT nor AT> is specified for an allocatable section,
> the linker will set the LMA such that the difference between
> VMA and LMA for the section is the same as the preceding output
> section in the same region.
Too clever and surprising to my taste. I'd invent new syntax for such a
feature, provided it's indeed that convenient.
[...]
> This is a change in the linker's behaviour that was made for the 2.18
> release. There is even a mention of it in the NEWS file.
I'm sorry I didn't check the NEWS file before reporting it as a bug, --
it just looked so obviously wrong that I didn't even think it could be a
feature. At the very beginning of the "Output Section LMA" of the old
manual it was written:
"The linker will normally set the LMA equal to the VMA. You can
change that by using the `AT' keyword. The expression LMA that follows
the `AT' keyword specifies the load address of the section."
So I had the following simple rules in my mind:
1. '>REGION' alone sets LMA=VMA and puts the section into the region.
2. 'AT' keyword is there to set LMA different from VMA, if required.
... and now 2.18 broke both of my precious rules (the second one due to
the fact that I now need to use AT to set VMA=LMA) :(
I think it was wrong idea to break backward compatibility for the sake
of "... a more useful default when using overlays and other cases where
you specify an LMA differing from the VMA for some sections", especially
when those new rules are rather questionable, as now one can't tell from
the definition of section alone if it has VMA=LMA or not.
> It does suggest a workaround for the problem: Change the "> RAM" in
> the description of the .bss section to "AT> RAM". ie:
>
>.bss : {
> . += 0x120;
>} AT> RAM
... now relying on the note in the documentation:
"Note that if the section has not had a VMA assigned to it then the
linker will use the LMA_REGION as the VMA region as well."
Seems like waiting for another clever trick that will change this one as
well...
So, due to the new rules, I should better change all of my "> R" to
">R AT>R", except where AT(addr) is used, e.g.:
.data: AT(addr) { ... } > RAM
.bss : { ... } > RAM AT> RAM
Seems like I'll need to learn to live with this...
> According to the manual this will set both the LMA and the VMA for the
> section, and you will end up with the same behaviour as the 2.16
> linker. (This change is backwards compatible, i.e. it will work with
> the 2.16 linker as well). Unfortunately there is a bug in the current
> linker sources such that the "AT> [region-name]" syntax is ignored
> unless there is also an "> [region-name-2]" specified for the
> section, and the two regions are different. I can see no good reason
> for this, and the behaviour certainly isn't documented, so I am
> planning to check in the uploaded patch to remove this restriction
> unless my regression testing shows up a problem.
Is this bug there in 2.18, or only on the HEAD?
Anyway, I'm glad my wrong bug report helped to find and fix real bug ;)
-- Sergei.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5788] New: Linker memory corruption
This patch
http://sourceware.org/ml/binutils/2007-02/msg6.html
causes a serious memory corruption in linker. There are 2 problems in
elf_create_symbuf:
ssymbuf = bfd_malloc ((shndx_count + 1) * sizeof (*ssymbuf)
+ (indbufend - indbuf) * sizeof (*ssymbuf));
if (ssymbuf == NULL)
{
free (indbuf);
return NULL;
}
ssym = (struct elf_symbuf_symbol *) (ssymbuf + shndx_count);
ssymbuf->ssym = NULL;
ssymbuf->count = shndx_count;
ssymbuf->st_shndx = 0;
1. Only one combined buffer is allocated for both ssymbuf and ssym.
But it is wrong to assume that size of ssym is the same as ssymbuf.
2. There are shndx_count + 1 entries in ssymbuf. ssym should
start at ssymbuf + shndx_count + 1, not ssymbuf + shndx_count
since the first entry is for shndx_count.
--
Summary: Linker memory corruption
Product: binutils
Version: 2.19 (HEAD)
Status: NEW
Severity: critical
Priority: P1
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: hjl dot tools at gmail dot com
CC: bug-binutils at gnu dot org,jakub at redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=5788
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5788] Linker memory corruption
--- Additional Comments From hjl dot tools at gmail dot com 2008-02-22 23:58 --- A patch is posted at http://sourceware.org/ml/binutils/2008-02/msg00228.html -- http://sourceware.org/bugzilla/show_bug.cgi?id=5788 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5788] Linker memory corruption
--- Additional Comments From hjl dot tools at gmail dot com 2008-02-23 00:03 --- Fixed. -- http://sourceware.org/bugzilla/show_bug.cgi?id=5788 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5788] Linker memory corruption
--- Additional Comments From hjl dot tools at gmail dot com 2008-02-23 00:03 --- Yes, fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=5788 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/868] bfd leaks memory in several places
--- Additional Comments From amodra at bigpond dot net dot au 2008-02-23 01:47 --- What is the point of the patch in comment #1? If we fail a realloc we are shortly going to exit with an error. Who cares if we haven't freed all memory? -- http://sourceware.org/bugzilla/show_bug.cgi?id=868 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
