http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
--- Comment #2 from Jan Hubicka <hubicka at ucw dot cz> 2011-01-08 13:43:27 UTC
---
> One failure is
>
> /tmp/ccJSP9PV.lto.o: In function `main':^M
> ccWUIi0z.o:(.text.startup+0x1d): undefined reference to `g_ebp_save'^M
> ccWUIi0z.o:(.text.startup+0x23): undefined reference to `g_esp_save'^M
> ccWUIi0z.o:(.text.startup+0x3b): undefined reference to `g_edi'^M
> ccWUIi0z.o:(.text.startup+0x41): undefined reference to `g_esi'^M
> ccWUIi0z.o:(.text.startup+0x47): undefined reference to `g_ebx'^M
> ccWUIi0z.o:(.text.startup+0x4d): undefined reference to `g_ebp'^M
> ccWUIi0z.o:(.text.startup+0x53): undefined reference to `g_esp'^M
> collect2: ld returned 1 exit status^M
Hmm, this does not seem to be dependent on plugin implementation, but it seems
like
bug in 32bit only testcase. The testcase seems to use:
int g_edi=INIT_EDI, g_esi=INIT_ESI, g_ebx=INIT_EBX;
int g_ebp, g_ebp_save, g_esp, g_esp_save;
int n_error;
and
__asm__ __volatile__ (
"movl %ebp," ASMNAME("g_ebp_save")"\n\t"
"movl %esp," ASMNAME("g_esp_save")"\n\t"
);
I guess either g_ebp_save needs externally_visible attribute or the asm
statement needs to be modified to use g_ebp_save as an destination.
I think this testcase is "yours", so perhaps you can fix it?
Was there some reason to use the ASMNAME hack instead of memory output
constraint?
Thanks,
Honza
