* `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o
@ 2006-05-16 15:28 Etienne Lorrain
2006-05-16 22:39 ` Alan Modra
0 siblings, 1 reply; 12+ messages in thread
From: Etienne Lorrain @ 2006-05-16 15:28 UTC (permalink / raw)
To: binutils
Hello,
While doing some automatic treatment (awk) of assembler files generated by GCC,
i.e. converting ".code16gcc \n calll fct \n" by ".code16gcc \n lcallw *ptr_fct \n"
I get this strange message (in the subject). It seems to be a warning because it
does not seem to stop the link process, but it is not preceded by a "Warning:"
prefix in stderr.
The version of ld I am using:
[etienne@localhost gujin]$ /home/etienne/projet/toolchain/bin/ld -v
GNU ld version 2.16.1
The exact modification I ask awk to do (add the 4 following lines):
1362 .section reloc_paramcode_section
1363 .weak fptr_linux_set_params
1364 0000 00000000 fptr_linux_set_params: .long linux_set_params
1365 .previous
1366 .section .paramcode_linux_set_params,"ax",@progbits
1367 .p2align 1,,1
1369 linux_set_params:
1370 0000 6655 pushl %ebp #
1371 0002 6657 pushl %edi #
1372 0004 6656 pushl %esi #
1373 0006 6653 pushl %ebx #
Plus an automatic transform of "call linux_set_params" by
"lcallw *fptr_linux_set_params".
I have already tried to use either ".globl fptr_linux_set_params" instead of
".weak fptr_linux_set_params".
My problem is when the function (for instance) linux_set_params is not used
at all in the link process, and is discarded because I am using GCC -ffunction-sections
and LD --gc-sections, it is still referenced in ".section reloc_paramcode_section"
which trigger this message:
[etienne@localhost gujin]$ /home/etienne/projet/toolchain/bin/ld boot.o user.o debug.o
library.o disk.o util.o gzlib.o kbd.o fs.o vmlinuz.o mouse.o main.o font.o -nostdlib
-Tboot.lnk -Map=boot.map --sort-common --cref --warn-section-align --no-check-sections
--gc-sections -o boot.elf
/home/etienne/projet/toolchain/bin/ld: `.paramcode_linux_set_params' referenced in
section `reloc_paramcode_section' of vmlinuz.o: defined in discarded section
`.paramcode_linux_set_params' of vmlinuz.o
Is there a trick to either not create symbol "fptr_linux_set_params:" in section
"reloc_paramcode_section" or not display this message (losing the 4 bytes for this
pointer is not a major problem).
Thanks a lot,
Etienne.
___________________________________________________________________________
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel.
Rendez-vous sur http://fr.yahoo.com/set
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o
2006-05-16 15:28 `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o Etienne Lorrain
@ 2006-05-16 22:39 ` Alan Modra
2006-05-16 22:47 ` Etienne Lorrain
0 siblings, 1 reply; 12+ messages in thread
From: Alan Modra @ 2006-05-16 22:39 UTC (permalink / raw)
To: Etienne Lorrain; +Cc: binutils
On Tue, May 16, 2006 at 01:34:25PM +0200, Etienne Lorrain wrote:
> My problem is when the function (for instance) linux_set_params is not used
> at all in the link process, and is discarded because I am using GCC -ffunction-sections
> and LD --gc-sections, it is still referenced in ".section reloc_paramcode_section"
What is special about reloc_paramcode_section? ie. How are you managing
to confuse the linker into thinking the reference in that section is not
a normal use, which should result in linux_set_params being kept?
Do you have a small self-contained testcase?
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o
2006-05-16 22:39 ` Alan Modra
@ 2006-05-16 22:47 ` Etienne Lorrain
2006-05-17 11:34 ` Alan Modra
0 siblings, 1 reply; 12+ messages in thread
From: Etienne Lorrain @ 2006-05-16 22:47 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
--- Alan Modra <amodra@bigpond.net.au> wrote:
> On Tue, May 16, 2006 at 01:34:25PM +0200, Etienne Lorrain wrote:
> > My problem is when the function (for instance) linux_set_params is not used
> > at all in the link process, and is discarded because I am using GCC
> > -ffunction-sections and LD --gc-sections, it is still referenced in
> > ".section reloc_paramcode_section"
>
> What is special about reloc_paramcode_section? ie. How are you managing
> to confuse the linker into thinking the reference in that section is not
> a normal use, which should result in linux_set_params being kept?
>
> Do you have a small self-contained testcase?
I do not know what is special about reloc_paramcode_section, but I noticed
the message do not appear if --no-check-sections is not a parameter of ld !!!
No testcase from C, but from assembler, with two files:
etienne@cygne:~/projet/gujin$ cat vmlinuz.s
.code16gcc
.psize 0
.section reloc_xcode_section
.weak fptr_treat_gzip_name
fptr_treat_gzip_name: .long treat_gzip_name
.previous
.section .xcode.treat_gzip_name,"ax",@progbits
.p2align 1,,1
.globl treat_gzip_name
.type treat_gzip_name, @function
treat_gzip_name:
pushl %edi #
pushl %esi #
pushl %edx #
movl 16(%esp), %edx # ptr, ptr
cmpl $LOADER+4, LOADER+76 #, LOADER.curfileload
jne .L266 #,
.L266:
popl %eax #
popl %esi #
popl %edi #
lretw $4 #
.size treat_gzip_name, .-treat_gzip_name
etienne@cygne:~/projet/gujin$ cat boot.lnk
MEMORY { ram : ORIGIN = 0, LENGTH = 64K }
EXTERN(__ERROR)
SECTIONS {
.text 0 : AT (0) {
/* boot.o(SORT(.text_start*)) */
/* KEEP (boot.o(.text_start*)); */
*(.text*)
__sizeof_gujin_code_in_text = . ;
. = ALIGN (32) ;
_etext = . ;
} > ram = 0
.xcode 0 : AT(SIZEOF(.text)) {
/* boot.o (.xcode_start) */
/* KEEP (boot.o(.xcode_start)); */
*(.xcode*)
__sizeof_gujin_code_in_extra = . ;
. = ALIGN (32) ;
} > ram = 0
__sizeof_all_code = SIZEOF(.text) + SIZEOF(.xcode);
.xdata 0 : AT(__sizeof_all_code) {
/* gzlib.o(.xdata*) */
/* font.o(.xdata*) */
. = ALIGN (8);
__paramcode_start = .;
*(.paramcode*)
__sizeof_paramcode = . - __paramcode_start;
*(.xdata*)
. = ALIGN (32);
_exdata = . ;
__sizeof_xdata = . ;
} > ram = 0
.data 0 : AT(__sizeof_all_code + __sizeof_xdata) {
*(.fourKsegment*)
_srodata = . ;
reloc_text_start = . ;
*(reloc_text_section)
reloc_text_end = . ;
reloc_xcode_start = . ;
*(reloc_xcode_section)
reloc_xcode_end = . ;
*(reloc_paramcode_section)
*(.rodata.str1*)
*(.rodata*)
. = ALIGN (32) ;
_erodata = . ;
__sizeof_constants = _erodata - _srodata ;
_end = . ;
_sdata = . ;
*(.data)
. = ALIGN (32);
_sbss = . ;
__sizeof_inited_data = _sbss - _sdata ;
} > ram = 0
.bss ALIGN(0x10) (NOLOAD) : {
*(COMMON) *(.bss)
. = ALIGN (4);
_edata = . ;
} > ram = 0
__sizeof_zeroed_data = SIZEOF (.bss) ;
.note (NOLOAD) : {
*(.note)
}
.comment (NOLOAD) : {
*(.comment)
}
.stab (NOLOAD) : {
*(.stab)
}
.stabstr (NOLOAD) : {
*(.stabstr)
}
}
NOCROSSREFS (.text .xcode);
EXTERN (xcodeseg_never_call_address_zero);
xcodeseg = SIZEOF(.text) >> 4 ;
_extext = SIZEOF(.xcode);
xdataseg = __sizeof_all_code >> 4;
deltaseg = (__sizeof_all_code + SIZEOF(.xdata)) >> 4;
etienne@cygne:~/projet/gujin$ as vmlinuz.s -o vmlinuz.o
etienne@cygne:~/projet/gujin$ ld vmlinuz.o -Tboot.lnk --no-check-sections --gc-sections
-o boot.elf
ld: warning: no memory region specified for loadable section `.rel.dyn'
ld: boot.elf: warning: allocated section `.data' not in segment
`treat_gzip_name' referenced in section `reloc_xcode_section' of vmlinuz.o: defined in
discarded section `.xcode.treat_gzip_name' of vmlinuz.o
etienne@cygne:~/projet/gujin$ ld vmlinuz.o -Tboot.lnk --gc-sections -o boot.elf
ld: error: no memory region specified for loadable section `.rel.dyn'
etienne@cygne:~/projet/gujin$
I think I really need the --no-check-sections, because most of my segments start
at 0 and have a max size of 64 Kbytes, so addresses in code and data overlap...
> Alan Modra
> IBM OzLabs - Linux Technology Centre
Thanks,
Etienne.
___________________________________________________________________________
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel.
Rendez-vous sur http://fr.yahoo.com/set
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o
2006-05-16 22:47 ` Etienne Lorrain
@ 2006-05-17 11:34 ` Alan Modra
2006-05-17 15:32 ` Fix regression introduced 2006-04-21 Alan Modra
2006-05-17 16:19 ` `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o Etienne Lorrain
0 siblings, 2 replies; 12+ messages in thread
From: Alan Modra @ 2006-05-17 11:34 UTC (permalink / raw)
To: Etienne Lorrain; +Cc: binutils
On Tue, May 16, 2006 at 05:28:41PM +0200, Etienne Lorrain wrote:
> --- Alan Modra <amodra@bigpond.net.au> wrote:
> > On Tue, May 16, 2006 at 01:34:25PM +0200, Etienne Lorrain wrote:
> > > My problem is when the function (for instance) linux_set_params is not used
> > > at all in the link process, and is discarded because I am using GCC
> > > -ffunction-sections and LD --gc-sections, it is still referenced in
> > > ".section reloc_paramcode_section"
> >
> > What is special about reloc_paramcode_section? ie. How are you managing
> > to confuse the linker into thinking the reference in that section is not
> > a normal use, which should result in linux_set_params being kept?
> >
> > Do you have a small self-contained testcase?
>
> I do not know what is special about reloc_paramcode_section, but I noticed
It's special because it is non-alloc, non-load. --gc-sections does not
remove such sections, but does not treat their relocs specially.
ie. unless reloc_paramcode_section is itself referenced from somewhere,
its relocs will not be examined to see whether other sections referenced
by it should be kept.
See http://sources.redhat.com/ml/binutils/2004-08/msg00178.html Perhaps
I should have restricted that change to sections without relocs. That
would still keep sections like .comment and .note.GNU-stack, but drop
your "special" section. I'm applying the following:
* elflink.c (elf_gc_sweep): Don't specially keep non-alloc,
non-load sections if they have relocs.
Index: bfd/elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.213
diff -u -p -r1.213 elflink.c
--- bfd/elflink.c 11 May 2006 15:55:40 -0000 1.213
+++ bfd/elflink.c 17 May 2006 00:28:23 -0000
@@ -8965,7 +8965,7 @@ elf_gc_sweep (bfd *abfd, struct bfd_link
{
/* Keep debug and special sections. */
if ((o->flags & (SEC_DEBUGGING | SEC_LINKER_CREATED)) != 0
- || (o->flags & (SEC_ALLOC | SEC_LOAD)) == 0)
+ || (o->flags & (SEC_ALLOC | SEC_LOAD | SEC_RELOC)) == 0)
o->gc_mark = 1;
if (o->gc_mark)
> the message do not appear if --no-check-sections is not a parameter of ld !!!
That would be because you are hitting a fatal error without
--no-check-sections.
> ld: error: no memory region specified for loadable section `.rel.dyn'
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 12+ messages in thread
* Fix regression introduced 2006-04-21
2006-05-17 11:34 ` Alan Modra
@ 2006-05-17 15:32 ` Alan Modra
2006-05-17 16:19 ` `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o Etienne Lorrain
1 sibling, 0 replies; 12+ messages in thread
From: Alan Modra @ 2006-05-17 15:32 UTC (permalink / raw)
To: binutils
When looking at Etienne's testcase, I saw some very wierd readelf
output. It turns out I introduced a bug with my 2006-04-21 change to
assign_file_positions_for_segments. I hadn't noticed an early exit from
the function when no section is mapped to segments, a possibility when
--gc-sections removes everything. The early exit meant that .shstrtab,
.symtab, and .strtab did not have their file positions set, and thus
overwrote the headers. Oops.
* elf.c (assign_file_positions_for_segments): Split into..
(assign_file_positions_for_load_sections): ..this, and..
(assign_file_positions_for_non_load_sections): ..this new function,..
(assign_file_positions_except_relocs): ..writing program headers here.
Index: bfd/elf.c
===================================================================
RCS file: /cvs/src/src/bfd/elf.c,v
retrieving revision 1.336
diff -u -p -r1.336 elf.c
--- bfd/elf.c 11 May 2006 12:34:46 -0000 1.336
+++ bfd/elf.c 17 May 2006 03:56:02 -0000
@@ -4106,24 +4106,20 @@ print_segment_map (bfd *abfd)
/* Assign file positions to the sections based on the mapping from
sections to segments. This function also sets up some fields in
- the file header, and writes out the program headers. */
+ the file header. */
static bfd_boolean
-assign_file_positions_for_segments (bfd *abfd, struct bfd_link_info *link_info)
+assign_file_positions_for_load_sections (bfd *abfd,
+ struct bfd_link_info *link_info)
{
const struct elf_backend_data *bed = get_elf_backend_data (abfd);
- unsigned int count;
struct elf_segment_map *m;
- unsigned int alloc;
Elf_Internal_Phdr *phdrs;
- file_ptr off, voff;
- bfd_vma filehdr_vaddr, filehdr_paddr;
- bfd_vma phdrs_vaddr, phdrs_paddr;
Elf_Internal_Phdr *p;
- Elf_Internal_Shdr **i_shdrpp;
- Elf_Internal_Shdr **hdrpp;
+ file_ptr off, voff;
+ unsigned int count;
+ unsigned int alloc;
unsigned int i;
- unsigned int num_sec;
if (elf_tdata (abfd)->segment_map == NULL)
{
@@ -4196,20 +4192,19 @@ assign_file_positions_for_segments (bfd
}
if (alloc == 0)
- alloc = count;
+ {
+ alloc = count;
+ elf_tdata (abfd)->program_header_size = alloc * bed->s->sizeof_phdr;
+ }
phdrs = bfd_alloc2 (abfd, alloc, sizeof (Elf_Internal_Phdr));
+ elf_tdata (abfd)->phdr = phdrs;
if (phdrs == NULL)
return FALSE;
off = bed->s->sizeof_ehdr;
off += alloc * bed->s->sizeof_phdr;
- filehdr_vaddr = 0;
- filehdr_paddr = 0;
- phdrs_vaddr = 0;
- phdrs_paddr = 0;
-
for (m = elf_tdata (abfd)->segment_map, p = phdrs;
m != NULL;
m = m->next, p++)
@@ -4345,11 +4340,6 @@ assign_file_positions_for_segments (bfd
if (! m->p_paddr_valid)
p->p_paddr -= off;
}
- if (p->p_type == PT_LOAD)
- {
- filehdr_vaddr = p->p_vaddr;
- filehdr_paddr = p->p_paddr;
- }
}
if (m->includes_phdrs)
@@ -4357,15 +4347,7 @@ assign_file_positions_for_segments (bfd
if (! m->p_flags_valid)
p->p_flags |= PF_R;
- if (m->includes_filehdr)
- {
- if (p->p_type == PT_LOAD)
- {
- phdrs_vaddr = p->p_vaddr + bed->s->sizeof_ehdr;
- phdrs_paddr = p->p_paddr + bed->s->sizeof_ehdr;
- }
- }
- else
+ if (!m->includes_filehdr)
{
p->p_offset = bed->s->sizeof_ehdr;
@@ -4376,14 +4358,6 @@ assign_file_positions_for_segments (bfd
if (! m->p_paddr_valid)
p->p_paddr -= off - p->p_offset;
}
-
- if (p->p_type == PT_LOAD)
- {
- phdrs_vaddr = p->p_vaddr;
- phdrs_paddr = p->p_paddr;
- }
- else
- phdrs_vaddr = bed->maxpagesize + bed->s->sizeof_ehdr;
}
p->p_filesz += alloc * bed->s->sizeof_phdr;
@@ -4538,9 +4512,39 @@ assign_file_positions_for_segments (bfd
}
}
- /* Assign file positions for the other sections. */
+ /* Clear out any program headers we allocated but did not use. */
+ for (; count < alloc; count++, p++)
+ {
+ memset (p, 0, sizeof *p);
+ p->p_type = PT_NULL;
+ }
+
+ elf_tdata (abfd)->next_file_pos = off;
+ return TRUE;
+}
+
+/* Assign file positions for the other sections. */
+
+static bfd_boolean
+assign_file_positions_for_non_load_sections (bfd *abfd,
+ struct bfd_link_info *link_info)
+{
+ const struct elf_backend_data *bed = get_elf_backend_data (abfd);
+ Elf_Internal_Shdr **i_shdrpp;
+ Elf_Internal_Shdr **hdrpp;
+ Elf_Internal_Phdr *phdrs;
+ Elf_Internal_Phdr *p;
+ struct elf_segment_map *m;
+ bfd_vma filehdr_vaddr, filehdr_paddr;
+ bfd_vma phdrs_vaddr, phdrs_paddr;
+ file_ptr off;
+ unsigned int num_sec;
+ unsigned int i;
+ unsigned int count;
+
i_shdrpp = elf_elfsections (abfd);
num_sec = elf_numsections (abfd);
+ off = elf_tdata (abfd)->next_file_pos;
for (i = 1, hdrpp = i_shdrpp + 1; i < num_sec; i++, hdrpp++)
{
struct elf_obj_tdata *tdata = elf_tdata (abfd);
@@ -4585,6 +4589,37 @@ assign_file_positions_for_segments (bfd
/* Now that we have set the section file positions, we can set up
the file positions for the non PT_LOAD segments. */
+ count = 0;
+ filehdr_vaddr = 0;
+ filehdr_paddr = 0;
+ phdrs_vaddr = bed->maxpagesize + bed->s->sizeof_ehdr;
+ phdrs_paddr = 0;
+ phdrs = elf_tdata (abfd)->phdr;
+ for (m = elf_tdata (abfd)->segment_map, p = phdrs;
+ m != NULL;
+ m = m->next, p++)
+ {
+ ++count;
+ if (p->p_type != PT_LOAD)
+ continue;
+
+ if (m->includes_filehdr)
+ {
+ filehdr_vaddr = p->p_vaddr;
+ filehdr_paddr = p->p_paddr;
+ }
+ if (m->includes_phdrs)
+ {
+ phdrs_vaddr = p->p_vaddr;
+ phdrs_paddr = p->p_paddr;
+ if (m->includes_filehdr)
+ {
+ phdrs_vaddr += bed->s->sizeof_ehdr;
+ phdrs_paddr += bed->s->sizeof_ehdr;
+ }
+ }
+ }
+
for (m = elf_tdata (abfd)->segment_map, p = phdrs;
m != NULL;
m = m->next, p++)
@@ -4657,22 +4692,8 @@ assign_file_positions_for_segments (bfd
}
}
- /* Clear out any program headers we allocated but did not use. */
- for (; count < alloc; count++, p++)
- {
- memset (p, 0, sizeof *p);
- p->p_type = PT_NULL;
- }
-
- elf_tdata (abfd)->phdr = phdrs;
-
elf_tdata (abfd)->next_file_pos = off;
- /* Write out the program headers. */
- if (bfd_seek (abfd, (bfd_signed_vma) bed->s->sizeof_ehdr, SEEK_SET) != 0
- || bed->s->write_out_phdrs (abfd, phdrs, alloc) != 0)
- return FALSE;
-
return TRUE;
}
@@ -4844,9 +4865,21 @@ assign_file_positions_except_relocs (bfd
}
else
{
+ unsigned int alloc;
+
/* Assign file positions for the loaded sections based on the
assignment of sections to segments. */
- if (! assign_file_positions_for_segments (abfd, link_info))
+ if (!assign_file_positions_for_load_sections (abfd, link_info))
+ return FALSE;
+
+ /* And for non-load sections. */
+ if (!assign_file_positions_for_non_load_sections (abfd, link_info))
+ return FALSE;
+
+ /* Write out the program headers. */
+ alloc = tdata->program_header_size / bed->s->sizeof_phdr;
+ if (bfd_seek (abfd, (bfd_signed_vma) bed->s->sizeof_ehdr, SEEK_SET) != 0
+ || bed->s->write_out_phdrs (abfd, tdata->phdr, alloc) != 0)
return FALSE;
off = tdata->next_file_pos;
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o
2006-05-17 11:34 ` Alan Modra
2006-05-17 15:32 ` Fix regression introduced 2006-04-21 Alan Modra
@ 2006-05-17 16:19 ` Etienne Lorrain
2006-05-19 11:50 ` Alan Modra
1 sibling, 1 reply; 12+ messages in thread
From: Etienne Lorrain @ 2006-05-17 16:19 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
--- Alan Modra wrote:
> It's special because it is non-alloc, non-load. --gc-sections does not
> remove such sections, but does not treat their relocs specially.
> ie. unless reloc_paramcode_section is itself referenced from somewhere,
> its relocs will not be examined to see whether other sections referenced
> by it should be kept.
>
> See http://sources.redhat.com/ml/binutils/2004-08/msg00178.html Perhaps
> I should have restricted that change to sections without relocs. That
> would still keep sections like .comment and .note.GNU-stack, but drop
> your "special" section. I'm applying the following:
>
> * elflink.c (elf_gc_sweep): Don't specially keep non-alloc,
> non-load sections if they have relocs.
>
> Index: bfd/elflink.c
> ===================================================================
> RCS file: /cvs/src/src/bfd/elflink.c,v
> retrieving revision 1.213
> diff -u -p -r1.213 elflink.c
> --- bfd/elflink.c 11 May 2006 15:55:40 -0000 1.213
> +++ bfd/elflink.c 17 May 2006 00:28:23 -0000
> @@ -8965,7 +8965,7 @@ elf_gc_sweep (bfd *abfd, struct bfd_link
> {
> /* Keep debug and special sections. */
> if ((o->flags & (SEC_DEBUGGING | SEC_LINKER_CREATED)) != 0
> - || (o->flags & (SEC_ALLOC | SEC_LOAD)) == 0)
> + || (o->flags & (SEC_ALLOC | SEC_LOAD | SEC_RELOC)) == 0)
> o->gc_mark = 1;
>
> if (o->gc_mark)
Thanks, that works:
/home/etienne/projet/toolchain/bin/ld boot.o user.o debug.o library.o disk.o util.o
gzlib.o kbd.o fs.o vmlinuz.o mouse.o main.o font.o -nostdlib -Tboot.lnk -Map=boot.map
--sort-common --cref --warn-section-align --no-check-sections --gc-sections -o boot.elf
/home/etienne/projet/toolchain/bin/ld: warning: no memory region specified for loadable
section `.rel.dyn'
/home/etienne/projet/toolchain/bin/objcopy --output-target=binary boot.elf boot.bin
> > ld: error: no memory region specified for loadable section `.rel.dyn'
Looks like that is now a warning - I do not understand why.
Someone on the list plans to remove the warning if the section is empty, or
shall I create a dummy?
Thanks again,
Etienne.
___________________________________________________________________________
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel.
Rendez-vous sur http://fr.yahoo.com/set
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o
2006-05-17 16:19 ` `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o Etienne Lorrain
@ 2006-05-19 11:50 ` Alan Modra
2006-05-19 15:30 ` Etienne Lorrain
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Alan Modra @ 2006-05-19 11:50 UTC (permalink / raw)
To: Etienne Lorrain; +Cc: binutils
On Wed, May 17, 2006 at 01:03:43PM +0200, Etienne Lorrain wrote:
> > > ld: error: no memory region specified for loadable section `.rel.dyn'
>
> Looks like that is now a warning - I do not understand why.
ld/
* ldlang.c (lang_size_sections_1): Don't check mem regions for
os->ignored sections.
ld/testsuite/
* ld-scripts/empty-orphan.t: Discard .reginfo.
* ld-scripts/empty-orphan.d: Update.
Index: ld/ldlang.c
===================================================================
RCS file: /cvs/src/src/ld/ldlang.c,v
retrieving revision 1.218
diff -u -p -r1.218 ldlang.c
--- ld/ldlang.c 17 May 2006 16:46:54 -0000 1.218
+++ ld/ldlang.c 19 May 2006 02:39:55 -0000
@@ -4198,7 +4198,8 @@ lang_size_sections_1
/* If a loadable section is using the default memory
region, and some non default memory regions were
defined, issue an error message. */
- if (!IGNORE_SECTION (os->bfd_section)
+ if (!os->ignored
+ && !IGNORE_SECTION (os->bfd_section)
&& ! link_info.relocatable
&& check_regions
&& strcmp (os->region->name,
Index: ld/testsuite/ld-scripts/empty-orphan.d
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-scripts/empty-orphan.d,v
retrieving revision 1.1
diff -u -p -r1.1 empty-orphan.d
--- ld/testsuite/ld-scripts/empty-orphan.d 17 Mar 2005 16:20:39 -0000 1.1
+++ ld/testsuite/ld-scripts/empty-orphan.d 19 May 2006 02:39:55 -0000
@@ -1,3 +1,10 @@
#source: empty-orphan.s
#ld: -T empty-orphan.t
-#error: no memory region specified for loadable section
+#readelf: -l --wide
+#...
+Program Headers:
+ +Type +Offset +VirtAddr +PhysAddr +FileSiz +MemSiz +Flg +Align
+ +LOAD +[x0-9a-f]+ 0x0+ 0x0+ 0x0+ 0x0+ .*
+ +LOAD +[x0-9a-f]+ 0x0+ 0x0+ 0x0+ 0x0+ .*
+ +LOAD +[x0-9a-f]+ [x0]+70000000 [x0]+70000000 [x0]+(2|4|8|10|20|40|80) .*
+#pass
Index: ld/testsuite/ld-scripts/empty-orphan.t
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-scripts/empty-orphan.t,v
retrieving revision 1.1
diff -u -p -r1.1 empty-orphan.t
--- ld/testsuite/ld-scripts/empty-orphan.t 17 Mar 2005 16:20:39 -0000 1.1
+++ ld/testsuite/ld-scripts/empty-orphan.t 19 May 2006 02:39:55 -0000
@@ -17,5 +17,6 @@ SECTIONS
.text : { *(.text) } > text_mem : text_phdr
.data : { *(.data) } > data_mem : data_phdr
.bss : { *(.bss) } > data_mem : data_phdr
+ /DISCARD/ : { *(.reginfo) }
/* .orphan_data is an orphan */
}
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o
2006-05-19 11:50 ` Alan Modra
@ 2006-05-19 15:30 ` Etienne Lorrain
2006-05-19 15:37 ` Alan Modra
2006-05-19 15:57 ` Etienne Lorrain
2 siblings, 0 replies; 12+ messages in thread
From: Etienne Lorrain @ 2006-05-19 15:30 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
--- Alan Modra wrote:
> On Wed, May 17, 2006 at 01:03:43PM +0200, Etienne Lorrain wrote:
> > > > ld: error: no memory region specified for loadable section `.rel.dyn'
> >
> > Looks like that is now a warning - I do not understand why.
>
> ld/
> * ldlang.c (lang_size_sections_1): Don't check mem regions for
> os->ignored sections.
> ld/testsuite/
> * ld-scripts/empty-orphan.t: Discard .reginfo.
> * ld-scripts/empty-orphan.d: Update.
>
> Index: ld/ldlang.c
> ===================================================================
> RCS file: /cvs/src/src/ld/ldlang.c,v
> retrieving revision 1.218
> diff -u -p -r1.218 ldlang.c
> --- ld/ldlang.c 17 May 2006 16:46:54 -0000 1.218
> +++ ld/ldlang.c 19 May 2006 02:39:55 -0000
> @@ -4198,7 +4198,8 @@ lang_size_sections_1
> /* If a loadable section is using the default memory
> region, and some non default memory regions were
> defined, issue an error message. */
> - if (!IGNORE_SECTION (os->bfd_section)
> + if (!os->ignored
> + && !IGNORE_SECTION (os->bfd_section)
> && ! link_info.relocatable
> && check_regions
> && strcmp (os->region->name,
Thanks, works for me.
Etienne.
___________________________________________________________________________
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel.
Rendez-vous sur http://fr.yahoo.com/set
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o
2006-05-19 11:50 ` Alan Modra
2006-05-19 15:30 ` Etienne Lorrain
@ 2006-05-19 15:37 ` Alan Modra
2006-05-19 15:57 ` Etienne Lorrain
2 siblings, 0 replies; 12+ messages in thread
From: Alan Modra @ 2006-05-19 15:37 UTC (permalink / raw)
To: binutils
On Fri, May 19, 2006 at 03:39:03PM +0930, Alan Modra wrote:
> * ld-scripts/empty-orphan.d: Update.
* ld-scripts/empty-orphan.d: Update again.
I should have waited until testing completed. xtensa trims off empty
PT_LOAD segments.
Index: ld/testsuite/ld-scripts/empty-orphan.d
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-scripts/empty-orphan.d,v
retrieving revision 1.2
diff -u -p -r1.2 empty-orphan.d
--- ld/testsuite/ld-scripts/empty-orphan.d 19 May 2006 06:10:03 -0000 1.2
+++ ld/testsuite/ld-scripts/empty-orphan.d 19 May 2006 11:46:49 -0000
@@ -2,9 +2,5 @@
#ld: -T empty-orphan.t
#readelf: -l --wide
#...
-Program Headers:
- +Type +Offset +VirtAddr +PhysAddr +FileSiz +MemSiz +Flg +Align
- +LOAD +[x0-9a-f]+ 0x0+ 0x0+ 0x0+ 0x0+ .*
- +LOAD +[x0-9a-f]+ 0x0+ 0x0+ 0x0+ 0x0+ .*
+LOAD +[x0-9a-f]+ [x0]+70000000 [x0]+70000000 [x0]+(2|4|8|10|20|40|80) .*
#pass
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o
2006-05-19 11:50 ` Alan Modra
2006-05-19 15:30 ` Etienne Lorrain
2006-05-19 15:37 ` Alan Modra
@ 2006-05-19 15:57 ` Etienne Lorrain
2006-05-20 13:56 ` Alan Modra
2 siblings, 1 reply; 12+ messages in thread
From: Etienne Lorrain @ 2006-05-19 15:57 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
Sorry, I may have talk a bit too quickly:
I am now trying to get rid of the unused sections (i.e. functions by having one
reloc_text_section_x per function) by the linker "ld --gc-sections", and after few
modifications I now get this similar message:
`.text.memcpy' referenced in section `reloc_text_section_0' of tmp.o: defined in
discarded section `.text.memcpy' of tmp.o
Testcase at end, just an intermediate question: Is there another way to handle
the relocation I am doing - do I bother for a problem already solved hundreds of
time already? I feel like reinventing the weel (how about a square one today?).
Thanks,
Etienne.
etienne@cygne:~/projet$ cat tmp.s
.code16gcc
.psize 0
.section reloc_text_section_0
.weak fptr_memcpy
fptr_memcpy: .long memcpy
.previous
.section .text.memcpy,"ax",@progbits
.p2align 1,,1
#awk .globl memcpy
.type memcpy, @function
memcpy:
pushl %ebx #
movl 16(%esp), %ebx # nb, nb
movl 8(%esp), %ecx # dest, ivtmp.141
movl 12(%esp), %edx # src, ivtmp.143
jmp .L4 #
.L5:
movb -1(%edx), %al #, tmp65
movb %al, -1(%ecx) # tmp65,
.L4:
decl %ebx # nb
incl %ecx # ivtmp.141
incl %edx # ivtmp.143
cmpl $-1, %ebx #, nb
jne .L5 #,
popl %ebx #
lretw $12 #
.size memcpy, .-memcpy
etienne@cygne:~/projet$ cat boot.lnk
MEMORY { ram : ORIGIN = 0, LENGTH = 64K }
EXTERN(__ERROR)
SECTIONS {
.text 0 : AT (0) {
*(.text*)
__sizeof_gujin_code_in_text = . ;
. = ALIGN (32) ;
_etext = . ;
} > ram = 0
.xcode 0 : AT(SIZEOF(.text)) {
*(.xcode*)
__sizeof_gujin_code_in_extra = . ;
. = ALIGN (32) ;
} > ram = 0
__sizeof_code = SIZEOF(.text) + SIZEOF(.xcode);
.xdata 0 : AT(__sizeof_code) {
. = ALIGN (8);
__paramcode_start = .;
*(.paramcode*)
__sizeof_paramcode = . - __paramcode_start;
*(.xdata*)
. = ALIGN (32);
_exdata = . ;
__sizeof_xdata = . ;
} > ram = 0
.data 0 : AT(__sizeof_code + __sizeof_xdata) {
*(.fourKsegment*)
_srodata = . ;
reloc_text_start = . ;
*(reloc_text_section_*)
reloc_text_end = . ;
reloc_xcode_start = . ;
*(reloc_xcode_section_*)
reloc_xcode_end = . ;
reloc_xdata_start = . ;
*(reloc_xdata_section_*)
reloc_xdata_end = . ;
*(reloc_paramcode_section)
*(.rodata.str1*)
*(.rodata*)
. = ALIGN (32) ;
_erodata = . ;
__sizeof_constants = _erodata - _srodata ;
_end = . ;
_sdata = . ;
*(.data)
. = ALIGN (32);
_sbss = . ;
__sizeof_inited_data = _sbss - _sdata ;
} > ram = 0
.bss ALIGN(0x10) (NOLOAD) : {
*(COMMON) *(.bss)
. = ALIGN (4);
_edata = . ;
} > ram = 0
__sizeof_zeroed_data = SIZEOF (.bss) ;
.note (NOLOAD) : {
*(.note)
}
.comment (NOLOAD) : {
*(.comment)
}
.stab (NOLOAD) : {
*(.stab)
}
.stabstr (NOLOAD) : {
*(.stabstr)
}
}
NOCROSSREFS (.text .xcode);
EXTERN (xcodeseg_never_call_address_zero);
xcodeseg = SIZEOF(.text) >> 4 ;
_extext = SIZEOF(.xcode);
xdataseg = __sizeof_code >> 4;
deltaseg = (__sizeof_code + SIZEOF(.xdata)) >> 4;
etienne@cygne:~/projet$
etienne@cygne:~/projet$ as tmp.s -o tmp.o
etienne@cygne:~/projet$ /home/etienne/projet/toolchain/bin/ld tmp.o -nostdlib -Tboot.lnk
--no-check-sections --gc-sections -o boot.elf
`.text.memcpy' referenced in section `reloc_text_section_0' of tmp.o: defined in
discarded section `.text.memcpy' of tmp.o
etienne@cygne:~/projet$
___________________________________________________________________________
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel.
Rendez-vous sur http://fr.yahoo.com/set
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o
2006-05-19 15:57 ` Etienne Lorrain
@ 2006-05-20 13:56 ` Alan Modra
0 siblings, 0 replies; 12+ messages in thread
From: Alan Modra @ 2006-05-20 13:56 UTC (permalink / raw)
To: Etienne Lorrain; +Cc: binutils
On Fri, May 19, 2006 at 02:39:06PM +0200, Etienne Lorrain wrote:
> `.text.memcpy' referenced in section `reloc_text_section_0' of tmp.o: defined in
> discarded section `.text.memcpy' of tmp.o
>
> Testcase at end
I get no errors with the testcase.
>, just an intermediate question: Is there another way to handle
> the relocation I am doing - do I bother for a problem already solved hundreds of
> time already?
I suspect you are on your own.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o
@ 2006-05-16 22:37 Etienne Lorrain
0 siblings, 0 replies; 12+ messages in thread
From: Etienne Lorrain @ 2006-05-16 22:37 UTC (permalink / raw)
To: binutils
Just to add that I get the same problem with "GNU ld version 2.16.92 20060416",
i.e.:
`.paramcode_linux_set_params' referenced in section `reloc_paramcode_section' of
vmlinuz.o: defined in discarded section `.paramcode_linux_set_params' of vmlinuz.o
but now it terminate the link with error (did I smoke crack when I said 2.16.1
was generating a result file? I then just check for the boot.map file).
Just I have a new (and unrelated) warning for my link with this binutils pre-release:
warning: no memory region specified for loadable section `.rel.dyn'
The section '.rel.dyn' is empty for my system, as said by boot.map:
.rel.dyn 0x00000000 0x0
.rel.text 0x00000000 0x0 boot.o
.rel.rodata 0x00000000 0x0 boot.o
.rel.text.start
0x00000000 0x0 boot.o
.rel.text.UI_function_init
0x00000000 0x0 boot.o
.rel.text.UI_init
0x00000000 0x0 boot.o
.rel.text.VESA_init
0x00000000 0x0 boot.o
... and all others of zero size ...
Thanks,
Etienne.
___________________________________________________________________________
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel.
Rendez-vous sur http://fr.yahoo.com/set
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2006-05-20 2:20 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-05-16 15:28 `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o Etienne Lorrain
2006-05-16 22:39 ` Alan Modra
2006-05-16 22:47 ` Etienne Lorrain
2006-05-17 11:34 ` Alan Modra
2006-05-17 15:32 ` Fix regression introduced 2006-04-21 Alan Modra
2006-05-17 16:19 ` `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o Etienne Lorrain
2006-05-19 11:50 ` Alan Modra
2006-05-19 15:30 ` Etienne Lorrain
2006-05-19 15:37 ` Alan Modra
2006-05-19 15:57 ` Etienne Lorrain
2006-05-20 13:56 ` Alan Modra
2006-05-16 22:37 Etienne Lorrain
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).