| 1 |
On Saturday, March 19, 2011 15:33:00 justin wrote: |
| 2 |
> I need your help figure out how to handle the situation. |
| 3 |
> |
| 4 |
> sample code is here: http://tinyurl.com/6ezv9uw |
| 5 |
|
| 6 |
dont do that. tinyurl's die, as do websites. just attach the code. see the |
| 7 |
one example func attached. |
| 8 |
|
| 9 |
is this the only way the define is used ? this file has no "64bit" behavior |
| 10 |
in it at all, only x86_64 ABI-specific behavior. |
| 11 |
|
| 12 |
the behavior it's looking at though really shouldnt be encoded into |
| 13 |
applications. apparently the code relies on whether stdargs generates a fresh |
| 14 |
list on the stack (and thus can be modified without modifying the original |
| 15 |
arguments), or if it refers directly to the original arguments. |
| 16 |
|
| 17 |
i'd have to look up what POSIX says on the matter, but if they're going to |
| 18 |
delving down that far into the ABI, then it sounds like the code is fairly |
| 19 |
fragile. but that's upstream's choice to write crap code. |
| 20 |
|
| 21 |
> the configure adds -D__amd64__ to C(PP)FLAGS. |
| 22 |
> |
| 23 |
> To me it should be set this on 64bit. Do I interpret that right? |
| 24 |
|
| 25 |
no. the compiler already takes care of defining __amd64__ for x86_64 targets, |
| 26 |
so there's no need to manually define it. |
| 27 |
|
| 28 |
so if this is the only place where __amd64__ is used, then you should make |
| 29 |
sure the configure code never manually appends it. |
| 30 |
-mike |
Archives