Re: Make more of the OLE interface vtables const

[Andreas Mohr]

Hi,

On Sun, May 29, 2005 at 07:05:49PM +0900, Dmitry Timoshkov wrote:
> Hello,
>
> Changelog:
>     Dmitry Timoshkov 
>     Make more of the OLE interface vtables const.

You do know that those will *not* end up const?

filemoniker.c:static const IClassFactoryVtbl FileMonikerCFVtbl =
objdump -x ole32.dll.so:
0008efb0 l     O .data  00000014              FileMonikerCFVtbl

My suspicion is that this is due to winegcc compile, all other binaries
with normal compile (e.g. winedump, ...) have all their const data in .rodata segment...

So, does anybody know what seems to be wrong with winegcc or why it chose to do that?

BTW, I already completely constified programs/ and tools/, will send a patch soon.

Andreas

Make more of the OLE interface vtables const

[Dimi Paun]

On Sun, 2005-05-29 at 20:49 +0200, Andreas Mohr wrote:
> So, does anybody know what seems to be wrong with winegcc or why it
> chose to do that?

winegcc is just a wrapper around gcc, it just passes stuff on to the
native compiler. I doubt it's because of that (unless some of the
additional options we pass have such an effect).

Make more of the OLE interface vtables const

[Dmitry Timoshkov]

"Andreas Mohr"  wrote:
> On Sun, May 29, 2005 at 07:05:49PM +0900, Dmitry Timoshkov wrote:
> > Hello,
> >
> > Changelog:
> >     Dmitry Timoshkov 
> >     Make more of the OLE interface vtables const.
>
> You do know that those will *not* end up const?
>
> filemoniker.c:static const IClassFactoryVtbl FileMonikerCFVtbl =
> objdump -x ole32.dll.so:
> 0008efb0 l     O .data  00000014              FileMonikerCFVtbl
>
> My suspicion is that this is due to winegcc compile, all other binaries
> with normal compile (e.g. winedump, ...) have all their const data in .rodata segment...
>
> So, does anybody know what seems to be wrong with winegcc or why it chose to do that?

It appears to be not a winegcc problem. That's how gcc generates pointer tables
(regardless of the pointer type). Although it (gcc) correctly produces warnings
about losing 'const' attribute while passing a pointer to a const table around, it
still places contents of the table into r/w section. I'd call it a gcc limitation,
if not a bug.

Still, IMO that shouldn't prevent us to do the right thing, and declare all
not writeable data as const.
> BTW, I already completely constified programs/ and tools/, will send a patch soon.

Great! Let's make Wine a better place on the planet :-)

Make more of the OLE interface vtables const

[Marcus Meissner]

On Mon, May 30, 2005 at 11:33:28AM +0900, Dmitry Timoshkov wrote:
> "Andreas Mohr"  wrote:
> > On Sun, May 29, 2005 at 07:05:49PM +0900, Dmitry Timoshkov wrote:
> > > Hello,
> > >
> > > Changelog:
> > >     Dmitry Timoshkov 
> > >     Make more of the OLE interface vtables const.
> >
> > You do know that those will *not* end up const?
> >
> > filemoniker.c:static const IClassFactoryVtbl FileMonikerCFVtbl =
> > objdump -x ole32.dll.so:
> > 0008efb0 l     O .data  00000014              FileMonikerCFVtbl
> >
> > My suspicion is that this is due to winegcc compile, all other binaries
> > with normal compile (e.g. winedump, ...) have all their const data in .rodata segment...
> >
> > So, does anybody know what seems to be wrong with winegcc or why it chose to do that?
>
> It appears to be not a winegcc problem. That's how gcc generates pointer tables
> (regardless of the pointer type). Although it (gcc) correctly produces warnings
> about losing 'const' attribute while passing a pointer to a const table around, it
> still places contents of the table into r/w section. I'd call it a gcc limitation,
> if not a bug.

The problem is that the pointers in the table need relocation, so it needs to
be modified during linking, so it cannot be fully const.

Ciao, Marcus