Small followup, seems it doesnt matter if I chain commands or not, using
cmd.exe to invoke commands will fail to detect output, even tho they
execute correctly.
* 1) cmd /C gcc -c -o test.o test.c
*** tup errors ***
tup error: Expected to write to file 'test.o' from cmd 20 but didn't
Perhaps cmd.exe starts sub-processes in a way we haven't hooked for...
And just noticed that one of the debug hooks provide erronous information
in tup_inject_dll:
DEBUG_HOOK("%s is WOW64: %i\n", GetCommandLineA(), bWow64);
>
gives you the calling process, witch in most cases is tup.exe, to get the
name of the process that tup starts up we need
TCHAR buffer[1024];
if (GetModuleFileNameEx(lpProcessInformation->hProcess,0,buffer,1024)){
DEBUG_HOOK("Executable: %s\n", buffer);
}
On Monday, November 3, 2014 2:51:21 PM UTC+1, Robert Pettersen wrote:
>
> Hi Mike,
>
> 1) See 2)
>
> 2) 32bit processes can not inject into 64bit processes. cmd.exe on 64bit
> windows is a bit of magic, haven't really figured it out. But that was the
> reason I put have_shell=1 yes. We have a special case where we chain a
> 32bit compiler with a 64bit compiler, and tup fails to detect output
> written. But the expected behaviour is achieved.
>
> 3) You are right, compiling with the 64bit compiler with the -m32 flag
> seem to produce the expected output.
>
> 4) Think we have to ifdef the entire function, or atleast pepper it
> somewhat. Wow64 is loading 32bit binaries from 64bit host (yeah, naming is
> a bit confusing), and the other case is 64bit from 64bit, but as you have
> seen, the function does not contain a proper loading of 32bit from 32bit.
> See the attached patch-diff for a suggestion. Have tested it and it seems
> to work, with the exception of the cmd chaining. Maybe you have better luck
> now that you know more about it.
>
> --
> Robert
>
> On Saturday, November 1, 2014 4:25:22 PM UTC+1, [email protected] wrote:
>>
>> Hi Robert, thanks so much for working on this! I think we are fairly
>> close.
>>
>> I've tried to incorporate this patch and produce both the
>> tup-dllinject.dll (64-bit) and tup-dllinject32.dll from the same tree. To
>> build binaries from Linux, you'll need both a CONFIG_TUP_MINGW and
>> CONFIG_TUP_MINGW32 in tup.config:
>>
>> CONFIG_TUP_MINGW=x86_64-w64-mingw32
>> CONFIG_TUP_MINGW32=i686-w64-mingw32
>>
>> I have a few questions so far, all pretty inter-related:
>>
>> 1) Why did you want to force have_shell=1 in windepfile.c? That causes
>> many of the tests to fail, so if it is truly necessary I'll have to find a
>> way to fix those tests (there are many). Or if there is some particular
>> case that doesn't work without it, I'll want to add a test to check for it
>> (and possibly fix it a different way)
>>
>> 2) Should it be possible to inject the 64-bit DLL into a 64-bit process
>> from a 32-bit process? For example, if I run "sh -c './64-test.exe'", then
>> sh (a 32-bit process) gets injected with a 32-bit dll, but 64-test.exe (a
>> 64-bit process) doesn't get injected. (Whereas if I just run 64-test.exe
>> directly, it gets injected fine since tup.exe is 64-bit). Is this why you
>> added have_shell=1 above?
>>
>> 3) Am I compiling the dllinjection code correctly? I left in the
>> @(TUP_32_BIT) code that you had commented out. (To be honest I'm not sure
>> what it's used for - I can't find the email thread or issue that talks
>> about it). Specifically, do I need to use both x86_64-w64-mingw32 and
>> i686-w64-mingw32? Or is there some way with -m64 / -m32 / -somethingelse
>> that we can just use x86_64-w64-mingw32?
>>
>> 4) The 64-bit DLL injection code won't compile with the 32-bit compiler,
>> since the CONTEXT structure no longer has the .Rip field. I put an #ifdef
>> around it, but I hit the "Error: Shouldn't be hooking here for the 32-bit
>> dll" message (something I added to your patch) when using sh -c
>> './64-test.exe' from question 2). Is there a better way to handle that?
>>
>> Hopefully we can get these sorted out & in the master branch soon.
>>
>> Thanks again,
>> -Mike
>>
>> On Wed, Aug 6, 2014 at 5:40 AM, Robert Pettersen <[email protected]>
>> wrote:
>>
>>> Hi,
>>>
>>> Really sorry about not posting any updates, been swamped with work and
>>> just got back from vacation. I don't have time to setup a git repo and
>>> commit the code, means I'll actually have to clean-up and comment the code.
>>> But I have attached a diff between the current origin/HEAD and the changes
>>> I made to get it working on 64bit host windows. Haven't made any changes
>>> since the initial work, since it has been stable for our use. Be warned
>>> tho, I have not tested this on a 32bit host system, it will however execute
>>> 32bit binaries on a 64bit host system.
>>>
>>> ~/tup64$ cat tup.config
>>>
>>> CONFIG_TUP_MINGW=x86_64-w64-mingw32
>>>
>>>
>>> I can probably answer some questions about the code and help out some
>>> here on the forum, but I can't guarantee their timelyness. Really swamped
>>> with work.
>>>
>>> Again, really sorry for not posting responses here sooner!
>>>
>>> On Monday, March 17, 2014 8:46:22 PM UTC+1, [email protected] wrote:
>>>
>>>> On Mon, Mar 17, 2014 at 8:51 AM, Tristan Rybak <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Mike, Robert,
>>>>> Any news on a patch for 64bit windows?
>>>>> I am using the executable attached to first post and it's working
>>>>> great (very big thanks for that Robert!)
>>>>> but I'd like to have new features and bugfixes introduced later too
>>>>> please.
>>>>> Maybe I could help with integrating the fix into repository somehow?
>>>>> Regards,
>>>>> Tristan
>>>>>
>>>>
>>>> Hi Tristan,
>>>>
>>>> I don't think I've seen the patch from Robert yet, though maybe I've
>>>> missed it. I'd be happy to get it included if he's interested in getting
>>>> it
>>>> upstream.
>>>>
>>>> Thanks,
>>>> -Mike
>>>>
>>> --
>>> --
>>> tup-users mailing list
>>> email: [email protected]
>>> unsubscribe: [email protected]
>>> options: http://groups.google.com/group/tup-users?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "tup-users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
--
--
tup-users mailing list
email: [email protected]
unsubscribe: [email protected]
options: http://groups.google.com/group/tup-users?hl=en
---
You received this message because you are subscribed to the Google Groups
"tup-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
