Re: Is the current ld brolen? (Re: ld is broken on Linux/alpha)

[Andreas Schwab <schwab at suse dot de>]

Jakub Jelinek <jakub@redhat.com> writes:

|> On Sat, Nov 24, 2001 at 11:24:39PM -0800, H . J . Lu wrote:
|> > Does your gcc support SHF_MERGE/STT_SECTION?
|> 
|> Surely I was.
|> 
|> > Did you see the linker messages during the build?
|> 
|> I missed them in the log but now I'm seeing there too:
|> 
|>         .section        .rodata.str1.1,"aMS",@progbits,1
|> .LC0:
|>         .string "."
|> ...
|>         leal    5+.LC0@GOTOFF(%ebx), %ecx
|> 
|> No idea why it takes address 3 bytes beyond end of the string.
|> (in C there is strcpy(buf, "."); ).
|> 
|> Now the question is whether this should be allowed or not.
|> If yes, then gas will have to revert back to keeping .LC* symbols in some
|> cases. Worst case relocs against SHF_MERGE symbols could be optimized to
|> STT_SECTION + addend in debugging sections only, but the more they are, the
|> more we save in object files.
|> 
|> Is
|> char *p = "foo" + 20;
|> where p will be never dereferenced ok wrt. C standard?

The C standard is clear about "foo" + 20 being undefined (even if not
dereferenced), but that does not tell anything about the assembler level,
where it is legal (at least on a non-segmented, linear memory model).

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5