Hello, don't know if it's the same issue, but a while ago I tried (on Windows) to create 32 and 64 bit object files (tcc only creates elf not coff) and wanted to convert them to coff with Agner Fog's objconv. Objconv was able to convert the 32 bit object files, but the 64 bit object files have been rejected due to wrong relocation type.
Maybe this issue is related. If so thank you for the fix. bye BTW: Maybe someone else can take Agner Fog's objconv and try to convert object files to see how well tcc creates 32/64 bit object files. ----- Original Message ----- From: "Andrew Mulbrook" <[email protected]> To: [email protected] Sent: Tuesday, February 28, 2012 8:22:07 AM Subject: Re: [Tinycc-devel] Strange issue with 64bit section offsets The goal is creating a 64bit ELF executable on Windows64. (The toy kernel reads ELF files only, not PE). I rant into a few issues along the way. Much of the ELF writing code assumes that "long" is 64 bits, not true on Win64 with "long long" insanity. The ELF executable sections were missing the high order bytes, followed by relocations not appearing to propagate the higher order bytes as well. First, the parsed string dropped the remaining bits (leaving vaddr of 0x00000000ffff8000), modifying to parse the entire got me to dropping the high order to relocate everything to 0x0. From there, it was trying to find all the places that appeared to not update the high words, resulting in portions of the executable located at 0xffff80000000 and looking at 0x0. Fwiw, I'm not the most familiar with git (professionally stuck with svn and using hg), and this patch was very much a hatchet job following a couple chains of events until the executable looked ok-ish. The toy kernel looks to be running ok, with only a couple headaches (ugh xmmX is used for varargs! - I might be writing a patch for this too). I can give it another go around this weekend or separate it into a few if you want. Fwiw, I think a much safer approach here would be killing the #define and switching to <stdint.h> with uint64_t and friends. Of course, you'd need to provide that(or similar) header for non-standards compliant / older compilers. While that wouldn't eliminate the other challenge of portable "strto*" functions, it'd mitigate the cross compilers overly relying on architecture type sizes. Regards, Andrew After fixing this, it appeared that On Tue, Feb 28, 2012 at 9:26 AM, grischka < [email protected] > wrote: Andrew Mulbrook wrote: <blockquote> Hi grischka, Looks like this rabbit hole went a bit further than I expected. After a bit of work, I managed to have (what appears) to be a valid test linked file located in an address space using the top word bits. I pushed "64bit_fixes:mob". However, I'm guessing more work needs done for the 64bit side of life on windows. This patch attempts to be fairly small in the changes it makes. Still I don't understand the point of most of these changes. Also the patch doesn't seem to fix the central issue. Was it not to make -Wl,-Ttext=0xffffff8000000000 work for windows-64, in the first place? --- grischka ______________________________ _________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/ mailman/listinfo/tinycc-devel </blockquote> _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
