This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH [1/n]: Initial x32 support


> It seems to me like these should be able to use the same set of conditions 
> as used for bits/syscall.h to handle an arbitrary number of variants.  
> Maybe rename the variables used for that from syscall-list-* to 
> multiarch-header-* or similar, move them out of sysdeps/unix/sysv/linux/ 
> to non-OS-specific directories and use the same set of conditions in the 
> generated headers?  That is, if syscall-list-variants (under its new name) 
> says "32bit 64bit" then <gnu/lib-names.h> and <gnu/stubs.h> would have 
> conditions to include -32bit and -64bit versions, and the #if conditions 
> would be as in syscall-list-32bit-condition and 
> syscall-list-64bit-condition.

That sounds very right to me.

> > 	* configure.in: Add sysdeps preconfigure fragment support.
> 
> The principle of having such a fragment is good, but I think you're 
> running them too late.  I think you should run sysdeps preconfigure 
> fragments (all of them) from libc at around the same time they are run for 
> add-ons.  This allows libc targets to look more like ports ones in that 
> the code

I'm not sure I follow this notion at all.  The reason I added preconfigure
was for things that need to influence the sysdirs list algorithm, like
setting base_machine and so forth.  Once the sysdirs list has been chosen,
we have sysdeps configure fragments.  So what's a sysdeps preconfigure for?


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]