public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Etienne Lorrain <etienne_lorrain@yahoo.fr>
To: Alan Modra <amodra@bigpond.net.au>
Cc: binutils@sourceware.org
Subject: Re: `.sym' referenced in section `reloc_sym' of file.o: defined in discarded section `.text.sym' of file.o
Date: Tue, 16 May 2006 22:47:00 -0000	[thread overview]
Message-ID: <20060516152841.79869.qmail@web26907.mail.ukl.yahoo.com> (raw)
In-Reply-To: <20060516150145.GI19700@bubble.grove.modra.org>

--- 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

  reply	other threads:[~2006-05-16 15:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-16 15:28 Etienne Lorrain
2006-05-16 22:39 ` Alan Modra
2006-05-16 22:47   ` Etienne Lorrain [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060516152841.79869.qmail@web26907.mail.ukl.yahoo.com \
    --to=etienne_lorrain@yahoo.fr \
    --cc=amodra@bigpond.net.au \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).