Re: libiberty testsuite builds with wrong compiler
Jack Howarth wrote: > The same issue in the libiberty testsuite run can be seen with > the Apple regress server log at > http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip. > If you search for test-demangle, you will find... I'm sure there is a bugzilla entry for that. Paolo
generated movaps with unaligned memory
Hi,
my shared library crashes with movaps instruction using not aligned memory.
Since the shared library function is being called from dynamic linker, which
basically prepares the memory location, I'm not sure whoose side issues this is.
I have following function in C:
typedef float La_x86_64_xmm __attribute__ ((__vector_size__ (16)));
typedef struct La_x86_64_retval
{
uint64_t lrv_rax;
uint64_t lrv_rdx;
La_x86_64_xmm lrv_xmm0;
La_x86_64_xmm lrv_xmm1;
long double lrv_st0;
long double lrv_st1;
} La_x86_64_retval;
unsigned int la_x86_64_gnu_pltexit (Elf64_Sym *__sym,
unsigned int __ndx, uintptr_t *__refcook, uintptr_t *__defcook,
const La_x86_64_regs *__inregs, La_x86_64_retval
*__outregs, const char *symname)
{
La_x86_64_xmm b __attribute__ ((aligned(16)));
b = __outregs->lrv_xmm0;
return 0;
}
this will endup in following assembly:
07d7 :
7d7: 55 push %rbp
7d8: 48 89 e5mov%rsp,%rbp
7db: 48 89 7d e8 mov%rdi,-0x18(%rbp)
7df: 89 75 e4mov%esi,-0x1c(%rbp)
7e2: 48 89 55 d8 mov%rdx,-0x28(%rbp)
7e6: 48 89 4d d0 mov%rcx,-0x30(%rbp)
7ea: 4c 89 45 c8 mov%r8,-0x38(%rbp)
7ee: 4c 89 4d c0 mov%r9,-0x40(%rbp)
7f2: 48 8b 45 c0 mov-0x40(%rbp),%rax
7f6: 0f 28 40 10 movaps 0x10(%rax),%xmm0
7fa: 0f 29 45 f0 movaps %xmm0,-0x10(%rbp)
7fe: b8 00 00 00 00 mov$0x0,%eax
803: c9 leaveq
804: c3 retq
Looks like xmm0 register is being used to transfer the data. However
the structure's alignment is not 16, so it will crash.
Now I'm not sure who should take of it?
Should the dynamic linker, who is basically calling this function,
ensure the structure is aligned on 16 bytes?
Or should gcc make sure it works on aligned memory
when emits movaps? (looks more likely to me...)
Also is there any way to ask gcc to emit movups instead movaps?
That would be nice workaround :)
thanks for any hint/ideas/help
here are my gcc spec:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
regards,
jirka
Re: generated movaps with unaligned memory
On Mon, Feb 23, 2009 at 10:05 AM, Jiri Olsa wrote:
> Hi,
>
> my shared library crashes with movaps instruction using not aligned memory.
>
> Since the shared library function is being called from dynamic linker, which
> basically prepares the memory location, I'm not sure whoose side issues this
> is.
>
> I have following function in C:
>
> typedef float La_x86_64_xmm __attribute__ ((__vector_size__ (16)));
>
> typedef struct La_x86_64_retval
> {
> uint64_t lrv_rax;
> uint64_t lrv_rdx;
> La_x86_64_xmm lrv_xmm0;
> La_x86_64_xmm lrv_xmm1;
> long double lrv_st0;
> long double lrv_st1;
> } La_x86_64_retval;
>
> unsigned int la_x86_64_gnu_pltexit (Elf64_Sym *__sym,
> unsigned int __ndx, uintptr_t *__refcook, uintptr_t *__defcook,
> const La_x86_64_regs *__inregs, La_x86_64_retval
> *__outregs, const char *symname)
> {
> La_x86_64_xmm b __attribute__ ((aligned(16)));
> b = __outregs->lrv_xmm0;
> return 0;
> }
>
> this will endup in following assembly:
>
> 07d7 :
> 7d7: 55 push %rbp
> 7d8: 48 89 e5mov%rsp,%rbp
> 7db: 48 89 7d e8 mov%rdi,-0x18(%rbp)
> 7df: 89 75 e4mov%esi,-0x1c(%rbp)
> 7e2: 48 89 55 d8 mov%rdx,-0x28(%rbp)
> 7e6: 48 89 4d d0 mov%rcx,-0x30(%rbp)
> 7ea: 4c 89 45 c8 mov%r8,-0x38(%rbp)
> 7ee: 4c 89 4d c0 mov%r9,-0x40(%rbp)
> 7f2: 48 8b 45 c0 mov-0x40(%rbp),%rax
> 7f6: 0f 28 40 10 movaps 0x10(%rax),%xmm0
> 7fa: 0f 29 45 f0 movaps %xmm0,-0x10(%rbp)
> 7fe: b8 00 00 00 00 mov$0x0,%eax
> 803: c9 leaveq
> 804: c3 retq
>
>
> Looks like xmm0 register is being used to transfer the data. However
> the structure's alignment is not 16, so it will crash.
>
Where exactly is it crashed? Which the structure isn't aligned at 16byte?
--
H.J.
Re: generated movaps with unaligned memory
On Mon, Feb 23, 2009 at 7:35 PM, H.J. Lu wrote:
> On Mon, Feb 23, 2009 at 10:05 AM, Jiri Olsa wrote:
>> Hi,
>>
>> my shared library crashes with movaps instruction using not aligned memory.
>>
>> Since the shared library function is being called from dynamic linker, which
>> basically prepares the memory location, I'm not sure whoose side issues this
>> is.
>>
>> I have following function in C:
>>
>> typedef float La_x86_64_xmm __attribute__ ((__vector_size__ (16)));
>>
>> typedef struct La_x86_64_retval
>> {
>> uint64_t lrv_rax;
>> uint64_t lrv_rdx;
>> La_x86_64_xmm lrv_xmm0;
>> La_x86_64_xmm lrv_xmm1;
>> long double lrv_st0;
>> long double lrv_st1;
>> } La_x86_64_retval;
>>
>> unsigned int la_x86_64_gnu_pltexit (Elf64_Sym *__sym,
>> unsigned int __ndx, uintptr_t *__refcook, uintptr_t *__defcook,
>> const La_x86_64_regs *__inregs, La_x86_64_retval
>> *__outregs, const char *symname)
>> {
>> La_x86_64_xmm b __attribute__ ((aligned(16)));
>> b = __outregs->lrv_xmm0;
>> return 0;
>> }
>>
>> this will endup in following assembly:
>>
>> 07d7 :
>> 7d7: 55 push %rbp
>> 7d8: 48 89 e5mov%rsp,%rbp
>> 7db: 48 89 7d e8 mov%rdi,-0x18(%rbp)
>> 7df: 89 75 e4mov%esi,-0x1c(%rbp)
>> 7e2: 48 89 55 d8 mov%rdx,-0x28(%rbp)
>> 7e6: 48 89 4d d0 mov%rcx,-0x30(%rbp)
>> 7ea: 4c 89 45 c8 mov%r8,-0x38(%rbp)
>> 7ee: 4c 89 4d c0 mov%r9,-0x40(%rbp)
>> 7f2: 48 8b 45 c0 mov-0x40(%rbp),%rax
>> 7f6: 0f 28 40 10 movaps 0x10(%rax),%xmm0
>> 7fa: 0f 29 45 f0 movaps %xmm0,-0x10(%rbp)
>> 7fe: b8 00 00 00 00 mov$0x0,%eax
>> 803: c9 leaveq
>> 804: c3 retq
>>
>>
>> Looks like xmm0 register is being used to transfer the data. However
>> the structure's alignment is not 16, so it will crash.
>>
>
> Where exactly is it crashed? Which the structure isn't aligned at 16byte?
>
>
>
> --
> H.J.
>
sry, it crashes on this one
7f6: 0f 28 40 10 movaps 0x10(%rax),%xmm0
This structure/argument is not aligned at 16
La_x86_64_retval *__outreg
the '__outregs->lrv_xmm0' is at 16th byte of the structure...
jirka
Re: generated movaps with unaligned memory
On Mon, Feb 23, 2009 at 10:39 AM, Jiri Olsa wrote:
> On Mon, Feb 23, 2009 at 7:35 PM, H.J. Lu wrote:
>> On Mon, Feb 23, 2009 at 10:05 AM, Jiri Olsa wrote:
>>> Hi,
>>>
>>> my shared library crashes with movaps instruction using not aligned memory.
>>>
>>> Since the shared library function is being called from dynamic linker, which
>>> basically prepares the memory location, I'm not sure whoose side issues
>>> this is.
>>>
>>> I have following function in C:
>>>
>>> typedef float La_x86_64_xmm __attribute__ ((__vector_size__ (16)));
>>>
>>> typedef struct La_x86_64_retval
>>> {
>>> uint64_t lrv_rax;
>>> uint64_t lrv_rdx;
>>> La_x86_64_xmm lrv_xmm0;
>>> La_x86_64_xmm lrv_xmm1;
>>> long double lrv_st0;
>>> long double lrv_st1;
>>> } La_x86_64_retval;
>>>
>>> unsigned int la_x86_64_gnu_pltexit (Elf64_Sym *__sym,
>>> unsigned int __ndx, uintptr_t *__refcook, uintptr_t
>>> *__defcook,
>>> const La_x86_64_regs *__inregs, La_x86_64_retval
>>> *__outregs, const char *symname)
>>> {
>>> La_x86_64_xmm b __attribute__ ((aligned(16)));
>>> b = __outregs->lrv_xmm0;
>>> return 0;
>>> }
>>>
>>> this will endup in following assembly:
>>>
>>> 07d7 :
>>> 7d7: 55 push %rbp
>>> 7d8: 48 89 e5mov%rsp,%rbp
>>> 7db: 48 89 7d e8 mov%rdi,-0x18(%rbp)
>>> 7df: 89 75 e4mov%esi,-0x1c(%rbp)
>>> 7e2: 48 89 55 d8 mov%rdx,-0x28(%rbp)
>>> 7e6: 48 89 4d d0 mov%rcx,-0x30(%rbp)
>>> 7ea: 4c 89 45 c8 mov%r8,-0x38(%rbp)
>>> 7ee: 4c 89 4d c0 mov%r9,-0x40(%rbp)
>>> 7f2: 48 8b 45 c0 mov-0x40(%rbp),%rax
>>> 7f6: 0f 28 40 10 movaps 0x10(%rax),%xmm0
>>> 7fa: 0f 29 45 f0 movaps %xmm0,-0x10(%rbp)
>>> 7fe: b8 00 00 00 00 mov$0x0,%eax
>>> 803: c9 leaveq
>>> 804: c3 retq
>>>
>>>
>>> Looks like xmm0 register is being used to transfer the data. However
>>> the structure's alignment is not 16, so it will crash.
>>>
>>
>> Where exactly is it crashed? Which the structure isn't aligned at 16byte?
>>
>>
>>
>> --
>> H.J.
>>
>
>
> sry, it crashes on this one
>
> 7f6: 0f 28 40 10 movaps 0x10(%rax),%xmm0
>
> This structure/argument is not aligned at 16
> La_x86_64_retval *__outreg
>
> the '__outregs->lrv_xmm0' is at 16th byte of the structure...
>
Why isn't __outregs aligned at 16byte? According to x86-64 psABI,
La_x86_64_retval should be aligned at 16byte.
--
H.J.
Re: targed.md: copy_to_mode_reg or force_reg?
Joern Rennecke writes: >> By the way: Are there better places to ask such questions like in gcc-help? > > If you actually need a new gcc backend and want it to be done well. you > should instruct an experienced contractor to do it for you, or hire an > in-house expert. > > Your question reveals that you are not familiar with gcc, and further > suggests that you are trying to implement a new backend alone or in a team > lacking a gcc expert. This is likely to either fail or result in a > backend of substandard quality which will never make it into the FSF > repository. > You might eventually (after several years) improve and come up with a > proper backend, but you will likely pick up the necessary skills more > quickly if you start out with something less ambitious, like improving > an existing backend, and have your patches peer-reviewed on the gcc > mailing list. > Or if you directly cooperate in implementing your new backend with someone > who already has the necessary experience. > > Thus, although your orginal question is valid in principle on this list, > answering is not likely to really help you, nor are you likely to help > the GCC community in the forseeable future if you are working on an > over-ambitious project project. > Thus, there is little incentive for anybody knowledgable reading this > list to answer this question. > > If the same question had been asked in a different context, e.g. a small > patch to the x86 backend in order to support some new and exciting linux > application, the odds of getting a timely response would have been higher. This seems a little bit unfair to me. We do have volunteers, and we should encourage them. Our internals documentation is very weak. I never saw the original question, or I would most likely have answered it. It's of course true that context helps, and your answer to the question seemed like a good one. Ian
Disadvantage of c++
Hello together.
(Pleas read twice before you start to answer !)
There are now 3 projects I know using NASM for there backend tasks and link it
together with the front end c++ code.
I think I do the same, until c++ has a pointer object (reserved word, type
like object_ptr myallover_ptr) that can be assigned with every names address
( &classname, &membername, &myfunction, &myvalue, &main, myptr,
&myarray[2], ) in the same name space.
In that scope a second mechanism is needed to define, redefine the contents of
Such A Pointer (from now on SAP), to define its usage - ...
SAP = MyClass->&myfunction
call void SAP(); // call is my favorite for execution. Because
void SAP( int value1 ); //can be read as a declaration, but should be
executed. and
usage_cast< SAP > void SAP( int value1 ); // would not be handy enough
...
int myvar = call int SAP( int value1 ); //SAP holds a pointer (to a function?)
MyClass *pointer = SAP
SAP = &myvar;
SAP = myvar //error: only pointers are allowed
...
More examples:
char *mypointer = SAP;
int func( int, char ); SAP = &func; //not: func(...) - it is not executed
--declaration
class my1{ int myval; void func1(); }
class my2{ int myval; void func2(); }
class my3{ int myval; void func3(); }
my1 *m1;
my2 *m2;
my3 *m3;
SAP *SAP1 //or however it has to be defined.
SAP *array;
--code
m1 = new my1;
m2 = new my2;
m3 = new my3;
array = new SAP[500];
array[2] = &m3[1] //->func3, the address of the second object is assigned.
SAP1 = m1->&myval;
SAP1 = m2->&func2; call SAP1; call void SAP1(); //but
call void SAP1( int i ); //is an (error) in that scope
//The tracking of SAP can be done only inside of a class.
//If in one class SAP gets something assigned and in an other it gets executed
//then this above would be no error. The value of SAP can't then be tracked.
---
You'll ask when you need such a reserved word (SAP, call), wouldn't be very
often -> well, in every case you want to program OO that does not fit in the
class structure. That's not seldom. In my case it is at 2 of 3 projects, or
if you have special switches or ...
Or more simple: With C++ you do OOP but your are not allowed to program OO.
That's a very big difference. Now I understand when my professor said " OOP
will not exist a long time" and every one was then programming OO in Pascal
or Fortran or assembler. Now you have OOP in that languages, too (not
assembler).
If the writing of that all above would be possible, then you can also programm
OO in C++. That would bring very much power to C++. But it is like a
revolution. A devil that breaks though the tidily structur of C++, like in
the real life, too.
The need of this all is underlined by this side:
http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.4
Programmers need an easy to use language and not a highly work around one.
I often have the feeling with c++, - how can I crack it, and not, - well,
let's do it. For normal use c++ is a very fine thing and well designed. But
it allows only one strategy to get to an app. And there you waste most of the
time to squeeze your backend tasks in that structure.
A beginner can't use SAP, because its programs won't link or run. He has to
learn the use of classes and members like all others before, too. But when he
grows up and his tasks become more and more complex then he can do it and not
only that but more - all.
- think about, ... how it is in pascal, fortran, assembler, vtable, pointers
are only values in registers BP-16, EBP-32, RBP-64 or memory, every defined
name in c++ is a pointer of the same type int_16 or int_32 or int_64
system(CPU) dependent. A pointer is pointing to what, Does it matter?
A class is an array of count member pointers. Functions - push, pop, stack
overflow, mismatch. ...
- maybe 20 minuts, ...
- then read again.
bastl
Re: Disadvantage of c++
On Mon, Feb 23, 2009 at 07:30:24PM -0800, S. Beck wrote: > (Pleas read twice before you start to answer !) The gcc list is for the development of GCC itself, not development with GCC, not discussion of misfeatures in a particular programming language.
Please block henry2000 from the wiki
Hello, Can someone *please* ban this nutcase from the wiki? There is almost weekly spam added to the wiki from this account. Thanks, Gr. Steven
Re: generated movaps with unaligned memory
On Mon, Feb 23, 2009 at 7:48 PM, H.J. Lu wrote:
> On Mon, Feb 23, 2009 at 10:39 AM, Jiri Olsa wrote:
>> On Mon, Feb 23, 2009 at 7:35 PM, H.J. Lu wrote:
>>> On Mon, Feb 23, 2009 at 10:05 AM, Jiri Olsa wrote:
Hi,
my shared library crashes with movaps instruction using not aligned memory.
Since the shared library function is being called from dynamic linker,
which
basically prepares the memory location, I'm not sure whoose side issues
this is.
I have following function in C:
typedef float La_x86_64_xmm __attribute__ ((__vector_size__ (16)));
typedef struct La_x86_64_retval
{
uint64_t lrv_rax;
uint64_t lrv_rdx;
La_x86_64_xmm lrv_xmm0;
La_x86_64_xmm lrv_xmm1;
long double lrv_st0;
long double lrv_st1;
} La_x86_64_retval;
unsigned int la_x86_64_gnu_pltexit (Elf64_Sym *__sym,
unsigned int __ndx, uintptr_t *__refcook, uintptr_t
*__defcook,
const La_x86_64_regs *__inregs, La_x86_64_retval
*__outregs, const char *symname)
{
La_x86_64_xmm b __attribute__ ((aligned(16)));
b = __outregs->lrv_xmm0;
return 0;
}
this will endup in following assembly:
07d7 :
7d7: 55 push %rbp
7d8: 48 89 e5 mov %rsp,%rbp
7db: 48 89 7d e8 mov %rdi,-0x18(%rbp)
7df: 89 75 e4 mov %esi,-0x1c(%rbp)
7e2: 48 89 55 d8 mov %rdx,-0x28(%rbp)
7e6: 48 89 4d d0 mov %rcx,-0x30(%rbp)
7ea: 4c 89 45 c8 mov %r8,-0x38(%rbp)
7ee: 4c 89 4d c0 mov %r9,-0x40(%rbp)
7f2: 48 8b 45 c0 mov -0x40(%rbp),%rax
7f6: 0f 28 40 10 movaps 0x10(%rax),%xmm0
7fa: 0f 29 45 f0 movaps %xmm0,-0x10(%rbp)
7fe: b8 00 00 00 00 mov $0x0,%eax
803: c9 leaveq
804: c3 retq
Looks like xmm0 register is being used to transfer the data. However
the structure's alignment is not 16, so it will crash.
>>>
>>> Where exactly is it crashed? Which the structure isn't aligned at 16byte?
>>>
>>>
>>>
>>> --
>>> H.J.
>>>
>>
>>
>> sry, it crashes on this one
>>
>> 7f6: 0f 28 40 10 movaps 0x10(%rax),%xmm0
>>
>> This structure/argument is not aligned at 16
>> La_x86_64_retval *__outreg
>>
>> the '__outregs->lrv_xmm0' is at 16th byte of the structure...
>>
>
> Why isn't __outregs aligned at 16byte? According to x86-64 psABI,
> La_x86_64_retval should be aligned at 16byte.
>
>
>
> --
> H.J.
>
thanks,
then the issue is in the glibc dynamic linker _dl_runtime_profile function
(sysdeps/x86_64/dl-trampoline.S). Looks like it should ensure
the outregs parameter is aligned to 16.
resending to the glibc mailing lists
the gdb session showing not aligned outregs parameter of the
_dl_call_pltexit func:
...
(gdb) b _dl_call_pltexit
Function "_dl_call_pltexit" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (_dl_call_pltexit) pending.
(gdb) r
Starting program: /opt/crash
symbol __libc_start_main
symbol printf
Breakpoint 1, _dl_call_pltexit (l=0x77ffd000, reloc_offset=0,
inregs=0x7fffe418, outregs=0x7fffe3c8) at dl-runtime.c:408
408 {
(gdb)
I'm using the latest glibc git code
(commit a839a1d3f4fbc0d75acd0dc4cad10cf6141e4963)
let me know if you need more info..
thanks for help,
jirka
