Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263475AbUFYTaU (ORCPT ); Fri, 25 Jun 2004 15:30:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263775AbUFYTaT (ORCPT ); Fri, 25 Jun 2004 15:30:19 -0400 Received: from chaos.analogic.com ([204.178.40.224]:49544 "EHLO chaos.analogic.com") by vger.kernel.org with ESMTP id S263475AbUFYTaG (ORCPT ); Fri, 25 Jun 2004 15:30:06 -0400 Date: Fri, 25 Jun 2004 15:29:20 -0400 (EDT) From: "Richard B. Johnson" X-X-Sender: root@chaos Reply-To: root@chaos.analogic.com To: Daniel Jacobowitz cc: Pavel Machek , Andrew Morton , kernel list , Patrick Mochel Subject: Re: swsusp.S: meaningfull assembly labels In-Reply-To: <20040625184817.GA3939@nevyn.them.org> Message-ID: References: <20040625115936.GA2849@elf.ucw.cz> <20040625151858.GA27013@nevyn.them.org> <20040625184817.GA3939@nevyn.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3079 Lines: 95 On Fri, 25 Jun 2004, Daniel Jacobowitz wrote: > On Fri, Jun 25, 2004 at 12:02:47PM -0400, Richard B. Johnson wrote: > > On Fri, 25 Jun 2004, Daniel Jacobowitz wrote: > > > > > On Fri, Jun 25, 2004 at 08:37:45AM -0400, Richard B. Johnson wrote: > > > > NO! You just made those labels public! The LOCAL symbols need to > > > > begin with ".L". Now, if you have a 'copy_loop' in another module, > > > > linked with this, anywhere in the kernel, they will share the > > > > same address -- not what you expected, I'm sure! The assembler > > > > has some strange rules you need to understand. Use `nm` and you > > > > will find that your new labels are in the object file! > > > > > > Er, no. They'll show up in the object file. That doesn't mean they're > > > global; static symbols also show up in the object file. > > > > > > -- > > > Daniel Jacobowitz > > > > I got caught on these, thinking that they weren't globals when > > I made a assembly files that used, not only named labels but > > also definitions like: > > > > BUF = 0x08 > > LEN = 0x0c > > > > code: movl BUF(%esp), %ebx > > movl LEN(%esp), %ecx > > > > > > This was done in several files. When linked, I got 'duplicate synbol' > > errors. These symbols, while not 'globals' in the sense that 'C' > > code can link with them are global definitions that are seen by > > the linker and cause duplicate symbol errors. I went through > > Those are what gas calls absolute symbols. > > > the gas documentation, trying to find how to prevent these > > private symbols from being written to the object file and there > > is no command-line mechanism. You just have to start every name > > with .L to keep them local. > > > > When I used labels like 'code' above, even though not declared > > '.global', the labels also showed up as duplicate symbols when > > linking the resulting object files. > > Does this only happen in your world? Or were you using a broken > non-GNU linker? > It is the GNU linker > drow@nevyn:~% cat a.s > BUF = 0x1 > code: > mov %eax, 0 > drow@nevyn:~% as -o a.o a.s > drow@nevyn:~% as -o b.o a.s > drow@nevyn:~% ld -o a a.o b.o > ld: warning: cannot find entry symbol _start; defaulting to 0000000008048074 > drow@nevyn:~% nm a.o > 00000001 a BUF > 00000000 t code > drow@nevyn:~% nm a > 00000001 a BUF > 00000001 a BUF > 08049084 A __bss_start > 08049084 A _edata > 08049084 A _end > 08048074 t code > 0804807c t code > > LD won't even warn about duplicate absolute symbols unless they have > different values. > But they ARE different values. They will probably always be different values, and they end up with the same name, that `ld` sees and complains. > -- > Daniel Jacobowitz > Cheers, Dick Johnson Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips). Note 96.31% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/