Re: [PATCH v2] Make '{add-,}symbol-file' not care about the position of command line arguments

[Pedro Alves <palves@redhat.com>]

On 11/30/2017 12:38 PM, Sergio Durigan Junior wrote:
> On Thursday, November 30 2017, Pedro Alves wrote:
> 
>> On 11/30/2017 04:24 AM, Sergio Durigan Junior wrote:
>>> Changes from v1:
>>>
>>> - Commit message has been rewritten.
>>>
>>> - Implemented position-independent argument parsing for
>>>   'add-symbol-file'.
>>>
>>> - Added testcases.
>>
>> Looks like you missed the comment about "--".  Take a look at
>> maintenance_print_symbols for an example of a command
>> that supports ending options with "--".  Can you add that
>> while you're at it, please?  For a test, I'd suggest
>> e.g., "symbol-file -- -non-existent-file" and confirming
>> gdb errors out.  That's simpler than actually creating a file.
> 
> Oh, I didn't understand that you were asking me to implement it.  I
> thought it was a comment for "something to be done later".  I'll do it,
> then.

I'd rather do it at the same time because there's the possibility
that implementing it suggests implementing any-position arguments
differently.  Or maybe not.  But I'd rather that we didn't have
to redo any-position support later on again.

>>
>> Does this push_back directly here mean that these
>> two commands end up with different semantics?
>>
>>  (gdb) add-symbol-file FILE 0 -s .text 0x1000
>>  (gdb) add-symbol-file -s .text 0x1000 FILE 0
> 
> The arguments are printed in a different order, yes:
> 
> (gdb) add-symbol-file -s .text 0x100 ./gdb/testsuite/outputs/gdb.base/relocate/relocate.o 0
> add symbol table from file "./gdb/testsuite/outputs/gdb.base/relocate/relocate.o" at
>         .text_addr = 0x100
>         .text_addr = 0x0
> (y or n) n
> Not confirmed.
> (gdb) add-symbol-file  ./gdb/testsuite/outputs/gdb.base/relocate/relocate.o 0 -s .text 0x100
> add symbol table from file "./gdb/testsuite/outputs/gdb.base/relocate/relocate.o" at
>         .text_addr = 0x0
>         .text_addr = 0x100
> (y or n) n
> Not confirmed.
> 
>> Not sure that's a good idea.
> 
> I'll work on it and make sure they're always printed in the same way.

TBC, the worry was not really about the printing (that's minor),
but what is the actual resulting .text address that the symbol file
it loaded at in the end.  But sounds like the printing order can
be used as proxy for checking that.  It's not as robust as
actually loading the symbols and then checking what happened
(with e.g., printing a symbol's address), but it's good
enough.

Thanks,
Pedro Alves