Re: How can I declare a global variable related to syscall routines without any issue?

[Bbbb Im <bjspam dot im at gmail dot com>]

Simply, I want, on some occasions, something else should be executed rather
than the original syscall instruction.

For example, in sysdeps/unix/sysv/linux/x86_64/sysdep.h;

#define internal_syscall0(number, err, dummy...) \
({ \
    unsigned long int resultvar; \
    if (!my_flag) {                                                    \
        asm volatile ( \
        "syscall\n\t" \
        : "=a" (resultvar) \
        : "0" (number) \
        : "memory", REGISTERS_CLOBBERED_BY_SYSCALL); \
    } else {                                                            \
        asm volatile ( \
        something else here .... );                             \
    }                                                                   \
    (long int) resultvar; \
})

I want 'my_flag' is set/unset by my newly created API and any syscalls
should be altered by those "something else here" thing.

Thank you.


2019년 12월 29일 (일) 오후 8:20, Paul Pluzhnikov <ppluzhnikov@google.com>님이 작성:

> On Sun, Dec 29, 2019 at 4:19 PM Bbbb Im <bjspam.im@gmail.com> wrote:
> >
> > Hi
> >
> > I am trying to modify x86-64 syscall routines to behave conditionally by
> a
> > flag variable.
>
> What are you trying to achieve?
> See also http://xyproblem.info/
>
> >  To do that, I added simple if statements in the
> > internal_syscall macros to check the value of the flag.
> > However, since they are macros, I need to declare the flag variable as a
> > global variable somewhere, then add "extern int" declaration in all C
> files
> > which call syscalll macros, and the object code which has the declaration
> > should be linked to all the objs with "extern" statements.
> > The problem is that which C file is the best place to declare the flag
> as a
> > global variable that does not break anything and linked to all the sycall
> > related C files? I could modify makefiles to link the declared obj files
> to
> > be linked to all others, but I am not sure it's the correct way to do it.
> >
> > Thank you.
>
>
>
> --
> Paul Pluzhnikov
>