This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch/rfc] Don't complain about unknown OSABI


> Code isn't the problem here.  It's the user-gdb interface.  Does the the 
> user model still work if there is more than one architecture.  Not 
> exploring the user-gdb interaction and instead just hacking code is how 
> we came to have all the CLI querks we've come to hate :-)
> 
> Anyway, I suspect just forcing the architecture when the OSABI is 
> changed is the most robust approach:
> 
> > (gdb) set osabi MIPS/GNU/Linux
> > Current architecture is NS32K, change to MIPS? (y or n)
> 
> ``the user is always right'' (no matter how silly it is :-).

But if gdb doesn't know how to handle the user's request, it doesn't 
matter how right the user is, they're still going to get garbage out of 
the debugger.

> I think it is also becomming aparent that there are several OSABI involved:
> 
> - the global default
> - the current instance
> 
> ``set osabi'' would change the current instance.

I think if we had the 'sniffer' code work as follows (I forget the names 
of the functions, but I think you'll get the drift):

	abi = sniff_osabi (abfd, allow_user_override);

	if (! handled_by_this_arch (abi))
	{
	  gdb_printf("Don't know how to handle abi '%s' on this architecture, "
		"using automatic detection", abi->name);
	  abi = sniff_osabi (abfd, force_sniff);
	}

Then each target arch can decide if it knows how to handle an ABI and if 
not force selection.

sniff_osabi would probably do

	if (allow_user_override && user_override != automatic)
		return user_override;
	/* start of auto-sniffer code.  */

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]