>>>>> "eric" == Eric W Biederman <ebiederm> writes:

 eric> Write valid C and you have a right to complain.  As is this is
 eric> invalid C, and the compiler can do anything it feels like.

I'm not complaining or pointing fingers.  I understand that what I'm
trying to do is not ANSI C, and any C compiler can validly reject this
code.  But gcc provides reasonable behavior for many constructs which
are not strictly conforming, which makes it a good tool for writing
low-level system code, such as kernels and (in my case) the target
language for a compiler.  The meaning of code which casts an arbitrary
address to a function pointer and then calls it is pretty clear, if
not technically allowed by the standard, so it's reasonable to ask if
it can be made to work in the one circumstance where it fails.

 eric> In particular you should write your code more like: typdef void
 eric> (*func_ptr)(void); extern func_ptr jump_table[];
 eric> jump_table[256]();

That approach would also work, and thank you for suggesting it, but it
means something different.  That's a table of function pointers rather
than a sequence of jump instructions.  I want my cross-module calls to
compile to simple call instructions, rather than loading a function
pointer out of some table (which is itself at a PC-relative address)
and then calling that.

 eric> To me the code just looks silly and bad.  If it has a
 eric> usefulness you might try asking how to do X.  Instead of saying
 eric> when I rely on non portable code the compiler doesn't do what I
 eric> expect.

Please don't flame me; I'm a C and compiler expert, I know exactly
what I'm doing.  Using C as the back end for a compiler occasionally
requires low-level hackery to make it generate the desired code.

gcc+as+ld are very close to doing what I want here, so I'm just asking
if they can be tweaked to handle this case.  And even if they can't,
if N+symbol@PLT is always an invalid thing to do then the assembler
should complain rather than silently dropping N.

By the way, I tried to work around this problem by using gcc's `asm
label' extension.  I specified an extern function declaration for my
test jump table entry and gave it the asm label "jump_table+2",
etc. hoping the "@PLT" won't appear in the resulting assembly code.
But it appends @PLT anyway (which is not unreasonable...)

-Mat

Reply via email to