[patch/peflags] Allow to change PE header stack and heap sizes

[Charles Wilson]

On 8/10/2011 4:12 AM, Corinna Vinschen wrote:
> In that case I prefer to use the offsetof macro on all hosts.  That's
> much simpler, right?

Sure, that's fine.
> 
> That's right, it just looks a bit convoluted.  Maybe the logic when to
> print something in peflags might need some revamping.

Yeah, reminds me of zork: a maze of twisty little passages, all alike...

> Apart from that, here's a question.  If the --verbose flag is given,
> should peflags print the sizeof values as well?  That's not the case
> right now.  I think changing the sizeof values is just a side job of
> peflags, so personally I'm not really sure I want to see the sizes on
> -v.  It would be a simple patch, of course:
> 
>       for (i = 0; i < NUM_SIZEOF_VALUES; ++i)
>         { 
> -         if (sizeof_vals[i].handle != DONT_HANDLE)
> +         if (verbose || sizeof_vals[i].handle != DONT_HANDLE)

I agree. If you're really that interested in printing ALL of the
stack/heap values for some .exe, you can either explicitly list them on
the cmd line: -X -x -Y -y -z --- or use objdump.

>>> +      if (option_index == 0 && c != long_options[0].val)
> 
> Good thinking.  Done in the patch below.

Ack.

>> I'm just wondering if, to avoid warnings, we need to explicitly cast the
>> RHS to ULONG.
> 
> In fact there are no warnings emitted by gcc, neither with Cygwin's nor
> with Ming64's gcc 4.5.3.  Keep in mind we're using -g -O2 -Wall -Werror
> all the time.  Everything's sufficently casted.

Oh, yeah, you're right.  I should have trusted the compiler rather than
my eyes. :-)

> Apart from the warnings, there *is* the issue that the user can enter
> something like --stack-reserve=0x1234567890 even if the executable is a
> 32 bit executable, and the value just gets truncated.
> 
> On second thought, the get_and_set_size function should emit a warning
> if somebody tries to change a 32 bit field to a 64 bit value.  I added
> that functionality to the below patch.

OK.

>> DO_READ doesn't have the same issue, because we're assigning a smaller
>> type to a larger storage, in that case; it just gets sign-extended.
> 
> Well, no.  The values are all unsigned, so there's no sign extension ;)

Right; unsigned types get zero-extended on promotion.

> New patch below,, with these additions to the ChangeLog:

Fine by me, with one addition:

+#include <stddef.h>

For some reason, the mingw.org headers don't include it automatically
via the other std*.h -- so you're missing the definition of the offsetof
macro without explicitly including stddef.

--
Chuck