Konstantinos Margaritis wrote:
Does anyone know what the impact of renaming these to use a REG_ prefix like i386, amd64 and sparc do* would be? at worst the packages that had to be workaround on arm* for this, can
have the workaround removed.
I have prepared a patch (attatched) that eliminates the dependency on sys/procfs.h and renames R? to REG_R?. I have tested it by modifying the header locally. I am now attempting to rebuild glibc with the patch. After rebuilding glibc I will install it and attempt to rebuild GDB.
Please comment on the patch and advise on the best route for submission (that is should I go through debian, through eglibc or direct to glibc?)
Since you're in the process of fixing things for glibc/arm
Note that I am not a glibc developer nor am I a dd (and even if I was a dd I don't think I would NMU glibc). I'm just a user with an interest in the future of debian on arm.
would you mind also looking at WCHAR_MIN/MAX undefined for arm?
They most certainly are defined. The trouble is that WCHAR_MAX is defined in a strange way.
#define __WCHAR_MAX ( (wchar_t) - 1 )
This definition is fine for normal c or c++ code but it cannot be properly evaluated in the context of a preprocessor conditional.
The bug report has a patch (actually a replacement for an existing patch) which looks fine to me.
On Sat, Dec 17, 2011 at 7:57 AM, peter green plugwash@p10link.net wrote:
mind also looking at WCHAR_MIN/MAX undefined for arm? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598937
They most certainly are defined. The trouble is that WCHAR_MAX is defined in a strange way.
#define __WCHAR_MAX ( (wchar_t) - 1 )
This definition is fine for normal c or c++ code but it cannot be properly evaluated in the context of a preprocessor conditional.
The bug report has a patch (actually a replacement for an existing patch) which looks fine to me.
ISO C99 says that WCHAR_MAX must be a constant expression and the above definition is such an expression. Technically the program needs fixing (see below though for the "standards matter but so do users"), there is nothing wrong with a type cast and a constant value e.g. signed -1 converted to unsigned int (ARM GNU/Linux value for wchar_t).
However, the real issue here is that it differs from x86, the most common architecture, and differences from x86 cause porting problems. The patch itself is insufficient because it doesn't take into account wordsize. When we switch to the 64-bit ARM ABI it should just work. Therefore you need to check for __WORDSIZE and *only* define a value if we are *not* 64-bits. You don't want to define anything for the 64-bit case until the 64-bit ARM ABI is out and finalized.
Your patch to fix ucontext namespace pollution looks good, please post that to libc-ports for review and make sure to state what testing you've done with the patch. At a minimum you should run the glibc testsuite and build gdb with those newly installed headers.
Cheers, Carlos.
ISO C99 says that WCHAR_MAX must be a constant expression and the above definition is such an expression. Technically the program needs fixing (see below though for the "standards matter but so do users"), there is nothing wrong with a type cast and a constant value e.g. signed -1 converted to unsigned int (ARM GNU/Linux value for wchar_t).
However, the real issue here is that it differs from x86, the most common architecture, and differences from x86 cause porting problems. The patch itself is insufficient because it doesn't take into account wordsize. When we switch to the 64-bit ARM ABI it should just work. Therefore you need to check for __WORDSIZE and *only* define a value if we are *not* 64-bits. You don't want to define anything for the 64-bit case until the 64-bit ARM ABI is out and finalized.
Thanks for the info, I may look at this later. The ucontext namespace pollution seems to be a bigger issue though.
Your patch to fix ucontext namespace pollution looks good, please post that to libc-ports for review
should I send it immidiately or should I wait until I have test results to give them?
and make sure to state what testing you've done with the patch. At a minimum you should run the glibc testsuite
Afaict the debian packaging automatically runs the testsuite and compares it against a list of expected failures (ideally that list would be empty but in real life....).
Right now i'm running into unexpected testsuite failures (unfortunately the last test build I didn't take a log of so i've got to run it again to find out details of the failures) but I do not know if those failures are related to my patch, related to changes in the build environment since the package was last built in debian or related to my hardware. Further testing will be neeed to establish that (and said testing takes a while, a beagleboard xm isn't exactly a speed demon).
and build gdb with those newly installed headers.
Will do once I get glibc built and installed, are there any specific tests you want doing with gdb or is testing it still builds sufficient??
Cheers, Carlos.
Thanks for the help and advice so-far.
On Sat, Dec 17, 2011 at 7:54 PM, peter green plugwash@p10link.net wrote:
Your patch to fix ucontext namespace pollution looks good, please post that to libc-ports for review
should I send it immidiately or should I wait until I have test results to give them?
Wait until the test results are complete and you've built gdb, this allows your patch to be accepted immediately if the maintainers agree that it's a good thing.
and make sure to state what testing you've done with the patch. At a minimum you should run the glibc testsuite
Afaict the debian packaging automatically runs the testsuite and compares it against a list of expected failures (ideally that list would be empty but in real life....).
Upstream wants to know that no new failures appeared with your patch.
and build gdb with those newly installed headers.
Will do once I get glibc built and installed, are there any specific tests you want doing with gdb or is testing it still builds sufficient??
In this case I think building gdb is sufficient.
However, the strongest case would be made by showing no regressions in the gdb testsuite with and without your glibc patch.
Cheers, Carlos.
-
Carlos O'Donell -
peter green