* `.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).