Re: [MinGW-dvlpr] MSYS "rebase" package

[Charles W. <cwi...@us...>]

On 5/27/2010 7:49 AM, Earnie wrote:
> Charles Wilson wrote:
>> [2] rebaseall feeds to rebase a list of DLLs, but not on the command
>> line.  The list of to-be-rebased DLLs is put in a file, and that file is
>> passed to rebase via its -T option.  So, since rebaseall is running
>> under msys-dash, the path to the file-containing-the-list will be
>> automagically converted to win32, but the *contents* of that file list
>> will not be.  I think this breaks rebaseall (and peflagsall).
>>
> 
> But rebaseall would read the list of dll from the file and spawn the 
> native rebase so the path would change from POSIX to WIN32 before rebase 
> sees the path.

No, rebase is called only once, and given the path to the file that
contains the list of DLLs.  So, the path to the listfile would get
converted, and then *rebase* reads the contents.  So, MSYS never gets
the chance to convert the paths listed inside the listfile.

The reason for the behavior on the part of rebase (e.g. called once to
act on a list of dll's, instead of being called multiple times to
operate singly on each dll) is so that rebase can do all the
book-keeping.  It determines the memory footprint of each DLL, and
increments (decrements) the base address to use for the *next* DLL by
that amount.  Otherwise, rebase would have to somehow indicate to the
script what the DLL's footprint was, and the script would have to track
that and use different -b 0xNNNNNNNN options on each call.

>> I dunno. Is there some accepted standard (<0x4000000 is .exe,>0x7000000
>> is system) or something?
>>
> 
> User space < 0x70000000 >= System space

Thanks. See here: http://www.drdobbs.com/184416272

> Applications (.exe files) start at 0x00400000 for all compilers
> that I tested.
...
> The address range for an application that is not reserved by any
> version of Windows is from 0x00400000 to 0x80000000. The system DLLs
> for Windows are currently based in memory from 0x70000000 to
> 0x78000000 on the Intel processors and from 0x68000000 to 0x78000000
> on the MIPS processors. Other standard DLLs (for OLE support) are
> apparently in the range 0x50000000 to 0x5f000000. When selecting base
> addresses for DLLs, Microsoft suggests that you select them from the
> top of the allowed address range downwards, in order to avoid
> conflicts with memory allocated dynamically by the application (which
> is allocated from the bottom up).
...
> In conclusion, the most suitable address range for DLLs is from
> 0x60000000  through 0x6f000000. Microsoft, seeking portability where
> it cannot be achieved, proposes to reduce the range further to
> 0x60000000  through 0x68000000 in order to accommodate both Intel and
> MIPS processors. (Also note that Microsoft’s upper limit overlaps the
> reserved range of the MIPS processor.) Microsoft’s proposal continues
> with a “first letter” scheme for the selection of the base address,
> which I have summarized in Table 1.

(Unfortunatly, the link to "Table 1" is broken)

>> 1) rebaseall and peflagsall both explicitly set PATH=/bin, they will
>> always use the rebase.exe (peflags.exe) in msys' /bin directory -- even
>> if a native version exists in /mingw/bin.
>>
> 
> I consider that a broken feature.  The assumption that the PATH should 
> be set to /bin is just wrong and should be fixed.

So, you WANT rebaseall, a particular script provided by a particular
package, which expects specific behavior and options from an executable
that is provided by *that same package*, to use whatever random
executable that happens to have the same name which it might find in the
PATH?  Especially when that PATH is *not* the normal path most MSYS
users are familiar with after they launch a "normal" shell via msys.bat?

I'm sorry, Earnie, but that's...not wise. It's ASKING for trouble.

The rebase.exe provided by the Microsoft SDK doesn't accept the -T
option. rebaseall uses it. That's one reason why PATH is explicitly set
to /bin. Also, remember that the recommended sequence is:

launch a dash shell
  * dash doesn't read the bash startup files, so your PATH is
    probably not what you're used to, in "regular" bash. Plus,
    you haven't run msys.bat, so all the PATH shenanigans it performs
    don't happen either.
  * In my case -- and that of many cygwin users -- I put neither
    the cygwin bin/ nor the MinGW/MSYS bin/ in my overall Windows
    PATH.  I rely on the .startup-files to do that.

run rebaseall
  * which needs to "find" sed, grep, gawk -- and rebase.exe.  Since the
    PATH is in an unusual state, rebaseall explicitly sets it to /bin.
    I don't see much difference between setting PATH=/bin and explicitly
    invoking every tool as /bin/foo.

>> 2) I believe that neither rebaseall nor peflagsall will work
>> successfully with a native rebase.exe (peflags.exe).
>>
> 
> And I disagree as noted above.

Because you misunderstand the situation.  rebase is NOT called in a
loop, nor are the DLL paths themselves listed on the command line -- so
MSYS doesn't get to fixup each individual path to the DLLs to be
rebased. The only path that appears in the command to rebase is the path
to the file containing the list -- so that's the only path that gets
fixed up; NOT the paths contained inside that listfile.

Now, both the Microsoft and Tishler versions of rebase CAN be called
with a list of DLLs passed explicitly on the command line.  In this
case, with a native version of rebase invoked within an msys-dash shell,
since each DLL pathname appears on the command line then MSYS would get
a chance to do its thing.

However, rebaseall doesn't do it that way, for two reasons: (1) command
line length limitations.  It's real easy to create a command line that's
too long, when you're listing every .dll in an entire installation. (2)
quoting issues. If the pathnames appeared on the command line, they'd
all need to be escaped/quoted to protect against shell special
characters and word splitting.

>> 3) An msys-rebase.exe (msys-peflags.exe) can't rebase (set flags on) the
>> msys-1.0.dll itself.
>>
>> So, how about a separate mingw32-rebase package, based on the same
>> source code, but which provides only the executables and not the
>> scripts? I'll probably have to update the msys-rebase package's
>> documentation to mention "the other one", but that's not too hard.
>>
> 
> And fix rebaseall and peflagsall so that it isn't setting the PATH or at 
> least provide a REBASE_PATH to be prepended to PATH.

Look at the code in rebaseall first, and then tell me if you still think
it'd be just great to use a native rebase with rebaseall. If so, then
I'll add REBASE_PATH support.

Oddly, however, nobody in six years on cygwin has ever found it
necessary to use *some other rebase* than the one *shipped with the
rebaseall* script.

--
Chuck