thank you. I meant - would it be feasible to _add_ to gcc needed pieces to make existing PE support (for x86 WinAPI target) available for at least MIPS32? and if so, where to start from? :) I mean, it's exactly compiler responsibility - if it sees __declspec(dllimport) on a function, it generates different call sequence, than if it were an ordinary, local function call. Since gcc already is able to do that with x86, maybe it's possible, by adding a little, to make it do the equivalent with, say, MIPS32. On the C side, it's the same and is already there. what's needed is to add CPU specific code generation for MIPS/PPC for this case. I would be happy to "patch" gcc to add that, but I need a little of help with the answer if it's feasible and where to start from if it is. :) 2019-06-21 21:35 GMT+03:00, Jim Wilson <jimw@xxxxxxxxxx>: > On Thu, Jun 20, 2019 at 3:48 PM valerij zaporogeci <vlrzprgts@xxxxxxxxx> > wrote: >> Hi. I want to build gcc, supporting PE for MIPS and PPC, that it >> understood declspec(dllimport) and export. Please tell me is this >> feasible? If so, could you direct me a little what I should start >> with? > > Only the ARM, mcore, and x86 ports support dllimport. PE is a > Microsoft specific object file format only supported for MS targets > like wince, but mips-wince-pe and powerpcle-wince-pe are both long > obsolete, and it looks like arm-wince-pe is obsolete too. I'm a > little surprised to find PE support for mcore; I don't know why that > is there. x86 pe should work, but it perhaps only works for > cygwin/mingw. If you look at old binutils and gcc versions you might > be able to find working mips-wince-pe or powerpcle-wince-pe support, > but this is unlikely to be easy to use or very useful. > > Jim >
