On Thu, Nov 26, 2009 at 11:20 PM, Garrett Cooper <[email protected]> wrote:
> On Thu, Nov 26, 2009 at 2:05 PM, Garrett Cooper <[email protected]> wrote:
>> It seems that the gcc / binutils WAS optimizing out a code branch
>> w.r.t. the syscall macro. I'm aware of the problem and trudging
>> through slowly working out compile time issues. I'll try to get it
>> done sometime tonight...
>
> Ok, I have a solution for these issues, but I want to make sure that
> what I'm doing is correct:
>
> gcoo...@orangebox /scratch/ltp-dev2/ltp $ cdiff
> testcases/kernel/include/regen.sh
> Index: testcases/kernel/include/regen.sh
> ===================================================================
> RCS file: /cvsroot/ltp/ltp/testcases/kernel/include/regen.sh,v
> retrieving revision 1.14
> diff -u -r1.14 regen.sh
> --- testcases/kernel/include/regen.sh 26 Nov 2009 22:08:52 -0000 1.14
> +++ testcases/kernel/include/regen.sh 27 Nov 2009 06:46:46 -0000
> @@ -29,7 +29,9 @@
> * result in compile-time errors and folks get the granularity they desire
> * when writing testcases.
> */
> -void cleanup(void) __attribute__ ((weak));
> +static void syscall_cleanup_stub(void) __attribute__ ((weakref ("cleanup")));
> +
> +static void cleanup(void);
>
> #define syscall(NR, ...) ({ \\
> int __ret; \\
> @@ -40,7 +42,8 @@
> __ret = syscall(NR, ##__VA_ARGS__); \\
> } \\
> if (__ret == -1 && errno == ENOSYS) { \\
> - tst_brkm(TCONF, cleanup, "syscall " #NR " not
> supported on your arch"); \\
> + tst_brkm(TCONF, syscall_cleanup_stub, \\
> + "syscall " #NR " not supported on your arch"); \\
> errno = ENOSYS; \\
> } \\
> __ret; \\
>
> This creates a weak reference to cleanup (which is undefined by
> default) and if someone specifies cleanup in a file that includes this
> header, it'll overwrite that with the strong reference, by design.
> Now, I used syscall_cleanup_stub for 1) readability, 2) to ensure
> that I didn't have to change a bunch of files that #include
> linux_syscall_numbers.h that define cleanup.
> I've tested it out in the following cases and it verified that it
> works as expected:
> 1. cleanup defined (strong reference) - put a printout in the
> strong reference copy of the cleanup function.
> 2. cleanup undefined (weak reference only).
> Is there any potential coverage I'm missing? Should this be
> defined somewhere else or be defined differently? My only concern is
> that this restricts the header to gcc-compatible compiler only
> compilation (icc included), as not all compilers have the
> __attribute__ qualifier.
> On the plus side, this gets past the previously mentioned build
> breakage and also mutes a lot of compiler warnings related to cleanup
> being unused / unreferenced, as it was previously just a function
> prototype in the header file.
After doing some reading, I spotted an unfortunate minute flaw in
this logic. I must explicitly note tst_exit after calling tst_brkm in
linux_syscall_numbers.h because the compiler / linker fills in 0 for
the cleanup function. Fun times... At least this is easy to fix.
Thanks,
-Garrett
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
