[PATCH-ping] VAX: Forced decoding of function entry masks (eg. for disassembling ROM images)

Jan-Benedict Glaw jbglaw@microdata-pos.de
Thu Mar 24 17:25:00 GMT 2005


On Thu, Mar 24, 2005 at 12:04:10PM +0000, Nick Clifton wrote:

Hi Nick!

> > I'd like to ping for my last patch, introducing the capability to
> > better disassemble ROM or MOP boot images with eg. objdump. Andreas'
> > objection about a limited number of entry addresses is fixed.
> 
> Sorry - it was in my queue to look at, but I am little behind at the moment.

No problem. I just didn't know about that:)

> > 2005-03-21  Jan-Benedict Glaw  <jbglaw@lug-owl.de>
> > 
> > 	opcodes/
> > 	* vax-dis.c: (struct private): Add a bfd_vma pointer to store
> > 	supplied function entry mask addresses.
> > 	(init_private_data): New; fill in supplied entry mask addresses.
> > 	(free_private_data): New; free() entry mask addresses.
> > 	(is_function_entry): Check if a given address is a function's
> > 	start address by looking at supplied entry mask addresses and
> > 	symbol information, if available.
> > 	(print_insn_vax): Use init_private_data(), is_function_entry()
> > 	and free_private_data().
> > 
> > 	binutils/doc/
> > 	* binutils.texi: Document new VAX disassembler-specific option
> > 	-M entry:0xfooba8.
> 
> Approved please apply, but...

I cannot do that on my own. AFAICT, I've only done all the FSF
paperwork, but that doesn't come along with write privilege (and
I'm not the VAX port maintainer).

> > +static int init_private_data
> > +  PARAMS ((struct disassemble_info *, struct private *));
> > +static void free_private_data PARAMS ((struct private *));
> > +static bfd_boolean is_function_entry
> > +  PARAMS ((struct disassemble_info *, bfd_vma addr));
> 
> We are using ISO C() now, so there is no need for the PARAMS macro.  In 
> fact if you place your function declarations carefully in the source 
> file then there is no need for static prototypes at all.

That's known. With *this* patch, I only wanted to introduce this
functionality. I'm about to prepare other patches to move the VAX bits
over to C90. That's on my list. (I also wrote that when the floating
point stuff was C90'fied by IIRC Alan yesterday or the day before...)

> > +static int
> > +init_private_data (info, priv)
> > +    struct disassemble_info *info;
> > +    struct private *priv;
> 
> Again ISO C90 means that you can include the argument declarations in 
> the parameter list, ie:

That'll come along with one of the next patches. I don't like fucking
up one file by mixing K&R C with C90, but I don't like messing up a
patch that introduces functionality /and/ formatting either. As I said,
C90'ification is on the list.

> Finally - it would be nice if you could come up with a new test for the 
> GAS testsuite that checks this functionality.

Testsuite is another thing. Basically, there's no for VAX, at least not
one that'll really do exhaustive tests. But this is on my list, too.

Near-time TODOs for me are:

	- This patch (which I mostly consider being done)
	- C90'fication
	- Testsuite updates to check correct code generation for _at
	  least_ all commonly used opcodes and all addressing modes.
	- Cut the long opcode table out of the vax.h header file and
	  place it into it's own vax-opc.c file as most other
	  architectures do it.
	- Maybe implement {en,de}coding of VAX vector opcodes

Longer term TODOs:
	- Make SMP VAXen to properly run with Linux
	- Find someone to work with me on GCC (throw out the CC0
	  stuff out of the .md file, really build a HEAD GCC for
	  NetBSD, introduce vax-dec-linux-gnu)
	- Fix glibc for vax-dec-linux-gnu

Long term TODO:
	- Make DEC^H^H^HCompaq^H^H^H^H^H^HHP to produce VAXen again:-)

MfG, JBG

-- 
AWEK microdata GmbH -- Am Wellbach 4 -- 33609 Bielefeld



More information about the Binutils mailing list