This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: PATCH: Allow a global symbol set to common/undefined symbol
- From: Daniel Jacobowitz <drow at false dot org>
- To: Etienne Lorrain <etienne_lorrain at yahoo dot fr>
- Cc: Nick Clifton <nickc at redhat dot com>, "H. J. Lu" <hjl at lucon dot org>,Dave Korn <dave dot korn at artimi dot com>, binutils at sources dot redhat dot com
- Date: Thu, 28 Apr 2005 10:07:20 -0400
- Subject: Re: PATCH: Allow a global symbol set to common/undefined symbol
- References: <20050428140208.88579.qmail@web26908.mail.ukl.yahoo.com>
On Thu, Apr 28, 2005 at 04:02:08PM +0200, Etienne Lorrain wrote:
> Sorry to bother again...
>
> With this patch and the source I am using, I have a problem elsewhere.
> It is initially due to GCC doing hidden real call to memcpy and
> memset when optimising for size (they consider calling those
> functions save space...)
>
> Basically because I am using two code segments (%cs can have two values
> to have twice 64 Kbytes accessible) I need two memcpy/memset, one in each
> segment. Because GCC insert real "call memset" I need to change the
> name of the function called in the assembler file - I am doing:
> asm ("memcpy = xcodeseg_memcpy \n");
> asm ("memset = xcodeseg_memset \n");
> So that "call memcpy" is replaced by "call xcodeseg_memcpy".
>
> With the H.J. patch in the assembler, I get messages:
> disk.s:7307: Error: Local symbol `memcpy' can't be equated to undefined
> symbol `xcodeseg_memcpy'
>
> I tried to define xcodeseg_memcpy as ".extern" of ".global" without
> success - even if they really are defined elsewhere.
>
> Is there a simple solution for my problem?
You need to mark memcpy as .globl, not xcodeseg_memcpy.
--
Daniel Jacobowitz
CodeSourcery, LLC