Non-multiarched macros

Non-multiarched macros

[Richard Earnshaw]

The following macros are defined by the ARM and are referenced by the 
generic code, but appear not be multi-arched.

What is supposed to happen here?

SMASH_TEXT_ADDRESS	  -- coffread.c dbxread.c dwarfread.c elfread.c
			     somread.c
FLOAT_INFO		  -- infcmd.c
VARIABLES_INSIDE_BLOCK    -- dbxread.c os9kread.c
ELF_MAKE_MSYMBOL_SPECIAL  -- elfread.c
COFF_MAKE_MSYMBOL_SPECIAL -- coffread.c

R.

Re: Non-multiarched macros

[Andrew Cagney]

> The following macros are defined by the ARM and are referenced by the 
> generic code, but appear not be multi-arched.
> 
> What is supposed to happen here?
> 
> SMASH_TEXT_ADDRESS	  -- coffread.c dbxread.c dwarfread.c elfread.c
> 			     somread.c
> FLOAT_INFO		  -- infcmd.c
> VARIABLES_INSIDE_BLOCK    -- dbxread.c os9kread.c
> ELF_MAKE_MSYMBOL_SPECIAL  -- elfread.c
> COFF_MAKE_MSYMBOL_SPECIAL -- coffread.c


Anyone can convert these macros to use the multi-arch framework and 
hopefull that conversion is a straight forward afair.  Easiest way I 
know to do this is to copy a similar example.  If you're wondering what 
isn't straight forward look at mips_extra_frame_info()  (Jason Thorp 
note - this stops the Alpha being fully converted, see gdb/150 and 
gdb/149 and gdb/151).

I'd do these in parallel with other changes since throwing the 
multi-arch switch doesn't depend on these being functions.

Some suggestions.

 > SMASH_TEXT_ADDRESS	  -- coffread.c dbxread.c dwarfread.c elfread.c
 > 			     somread.c

REGISTER_BYTES_OK

 > FLOAT_INFO		  -- infcmd.c

DO_REGISTERS_INFO

need to change FLOAT_INFO -> FLOAT_INFO().

 > VARIABLES_INSIDE_BLOCK    -- dbxread.c os9kread.c

Is OS9K_VARIABLES_INSIDE_BLOCK defined?
DO_REGISTERS_INFO

 > ELF_MAKE_MSYMBOL_SPECIAL  -- elfread.c

REGISTER_BYTES_OK

 > COFF_MAKE_MSYMBOL_SPECIAL -- coffread.c

REGISTER_BYTES_OK

There was an e-mail explaining the choice somewhere (Eli, I guess it is 
time to give in and put it into the internals manual).  However, briefly:

#ifdef FOO
    FOO()
#endif

becomes

    if (FOO_P())
     FOO();

and

#ifndef FOO
#define FOO() bar()
#endif
     FOO()

becomes

     FOO()

with bar() made the default.  The main thing is to resist any temptation 
to do anything beyond a mechanical conversion.

enjoy,
Andrew

Re: Non-multiarched macros

[Richard Earnshaw]

>  > ELF_MAKE_MSYMBOL_SPECIAL  -- elfread.c
> 
> REGISTER_BYTES_OK
> 
>  > COFF_MAKE_MSYMBOL_SPECIAL -- coffread.c
> 
> REGISTER_BYTES_OK

These two are my biggest concern.  They are likely to pull object-format 
specific information into the tdep file.  Is that safe?  Can I be sure 
that the all the object formats will be available there, regardless of 
configuration.

R.

Re: Non-multiarched macros

[Daniel Jacobowitz]

On Fri, Feb 01, 2002 at 05:03:51PM +0000, Richard Earnshaw wrote:
> 
> >  > ELF_MAKE_MSYMBOL_SPECIAL  -- elfread.c
> > 
> > REGISTER_BYTES_OK
> > 
> >  > COFF_MAKE_MSYMBOL_SPECIAL -- coffread.c
> > 
> > REGISTER_BYTES_OK
> 
> These two are my biggest concern.  They are likely to pull object-format 
> specific information into the tdep file.  Is that safe?  Can I be sure 
> that the all the object formats will be available there, regardless of 
> configuration.

Yep.  All the standard formats - including at least ELF and COFF -
will always be available, and no one really plans to change that.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Non-multiarched macros

[Andrew Cagney]

>> ELF_MAKE_MSYMBOL_SPECIAL  -- elfread.c
>> 
>> REGISTER_BYTES_OK
>> 
>> > COFF_MAKE_MSYMBOL_SPECIAL -- coffread.c
>> 
>> REGISTER_BYTES_OK
> 
> 
> These two are my biggest concern.  They are likely to pull object-format 
> specific information into the tdep file.  Is that safe?  Can I be sure 
> that the all the object formats will be available there, regardless of 
> configuration.


Dan answered the technical question.

Anyway, it is probably a design flaw (?) and multi-arch conversions 
ignore flaws in the design.  You can grit your teath and do the 
conversion anyway :-)

The rationale is two fold.  If people tried to fix every design flaw 
they found during the conversion process then the conversion process 
would never be finished.  Once everything is converted, it is going to 
be far easier for someone to go through all targets and test/fix the 
design problems.

enjoy,
Andrew