From: Gorton, R. <Ric...@am...> - 2010-10-06 18:45:04
|
Hi, I've got a need to port elftoolchain to Windows, and am in the process of doing so. Are there any particular process requirements in terms of feeding back the changes to get them integrated? A preferred diff command? My motivation here is to get a completely clean compile with no warnings. Some changes are small, at least one requires a deeper understanding of the intent of a fair amount of the implementation code - realloc(<address>, uint64_t) on a 32-bit os. An example is _dwarf_write_lsb_alloc() ... *block = realloc (*block, *size); where size is a parameter == uint64_t *size. On a 32-bit OS, size_t is uint32_t; the compiler legitimately warns about possible loss of data. In most cases, I suspect that a realloc() is not expected to be > 32bits in size, so the warning can mostly be ignored. One (moderately clean) way to detect/prevent the actual loss is to write a little jacket function: void *myrealloc (void ptr, uint64_t size) { size_t mysize = (size_t) size; if (size) != mysize) { DWARF_SET_ERROR(<stuff>); return NULL; } else { return realloc(ptr, mysize); } } And then have two different myrealloc functions, depending on the OS. Another choice is to explicitly cast size --> size_t knowing that the realloc() is always going to be < 32bits in size. Richard Gorton GPU Developer Tools |
From: Kai W. <kai...@gm...> - 2010-10-08 20:33:44
|
On Wed, Oct 06, 2010 at 01:44:46PM -0500, Gorton, Richard wrote: > > Hi, > > I've got a need to port elftoolchain to Windows, and am in the process of doing so. Are there any particular process requirements in terms of feeding back the changes to get them integrated? A preferred diff command? Sounds cool! Feedbacks are always appreciated :) Just curious, are you porting it to cygwin or native Windows? > My motivation here is to get a completely clean compile with no warnings. That's always our goal: clean code. [snip] > Another choice is to explicitly cast size --> size_t knowing that the realloc() is always going to be < 32bits in size. I agree with this apporach. realloc()/malloc() in libdwarf should be always < 32bits in size. I committed a fix in r1211. It'd be great if you can verify the warnings are gone. Thanks, Kai |
From: Joseph K. <jk...@us...> - 2010-10-09 06:03:05
|
> I've got a need to port elftoolchain to Windows, and am in the process of doing so. Best of luck! Our current porting targets are open-source POSIX systems. To the best of our knowledge, you would be the first person attempting a Windows(R) port. Changes that improve our code's portability would be welcome. Its also fair to point out upfront that we don't currently have a way to develop for the Windows(R) platform, so ongoing maintenance may be an issue unless someone with Windows expertise steps up to periodically build the code and keep it "live". > Are there any particular process requirements in terms of feeding back the changes to get them integrated? Just file a Trac ticket with your patch and we'll take it forward from there. > A preferred diff command? Any readable format will do, e.g., `diff -u`. > My motivation here is to get a completely clean compile with no warnings. Cool. Some questions: 1) What build environment are you using? Is it open-source? 2) How are you handling make rules---our makefiles are dependent on <sys.mk> doing the right thing. 3) libelf uses mmap() internally; how much of a portability hurdle is this? 4) Finally, are you attempting to port the test suites too? If so, any issues there? [...snip...] > Another choice is to explicitly cast size --> size_t knowing that the realloc() is always going to be < 32bits in size. In this case a (size_t) cast should be good enough---it would be a no-op on 64 bit systems, and 32 bit POSIX-like systems aren't going to be able to deal with memory arenas larger than process address space anyway. -- Koshy |
From: Gorton, R. <Ric...@am...> - 2010-10-11 12:30:14
|
I'm doing a native port to visual studio; we've got a build environment which uses a tool called bjam to do the compilations. As for the existing makefiles, I'll observe that gnu make (under ubuntu/64-bit) objects to ".include <bsd.subdir.mk>" in the top level makefile. I haven't looked at the tests at all. Rick -----Original Message----- From: ko...@un... [mailto:ko...@un...] On Behalf Of Joseph Koshy Sent: Saturday, October 09, 2010 1:35 AM To: Gorton, Richard Cc: elf...@li... Subject: Re: [Elftoolchain-developers] windows porting... > I've got a need to port elftoolchain to Windows, and am in the process of doing so. Best of luck! Our current porting targets are open-source POSIX systems. To the best of our knowledge, you would be the first person attempting a Windows(R) port. Changes that improve our code's portability would be welcome. Its also fair to point out upfront that we don't currently have a way to develop for the Windows(R) platform, so ongoing maintenance may be an issue unless someone with Windows expertise steps up to periodically build the code and keep it "live". > Are there any particular process requirements in terms of feeding back the changes to get them integrated? Just file a Trac ticket with your patch and we'll take it forward from there. > A preferred diff command? Any readable format will do, e.g., `diff -u`. > My motivation here is to get a completely clean compile with no warnings. Cool. Some questions: 1) What build environment are you using? Is it open-source? 2) How are you handling make rules---our makefiles are dependent on <sys.mk> doing the right thing. 3) libelf uses mmap() internally; how much of a portability hurdle is this? 4) Finally, are you attempting to port the test suites too? If so, any issues there? [...snip...] > Another choice is to explicitly cast size --> size_t knowing that the realloc() is always going to be < 32bits in size. In this case a (size_t) cast should be good enough---it would be a no-op on 64 bit systems, and 32 bit POSIX-like systems aren't going to be able to deal with memory arenas larger than process address space anyway. -- Koshy |
From: Joseph K. <jk...@us...> - 2010-10-11 13:05:52
|
> As for the existing makefiles, I'll observe that gnu make (under > ubuntu/64-bit) objects to ".include <bsd.subdir.mk>" in the top level > makefile. That is not surprising --- our Makefiles use BSD make syntax. See: http://crufty.net/help/sjg/bmake.html. -- Koshy |
From: Gorton, R. <Ric...@am...> - 2010-10-11 13:28:57
|
As I read through the compiler warnings, I'm arriving at the opinion that some of these need to remain warnings in a 32-bit environment: uint64_t/Dwarf_Unsigned conversions to Dwarf_Off (== off_t); uint64_t to size_t similarly. Most of these will only become a problem if the size of the file exceeds 32-bits; this is highly improbable for my target usage, but may be pertinent for others (perhaps 32-bit Linux, with very large executables), so I'm not going to fiddle with those. I hope to post a patch to the list later today. Rick |