Re: [PATCH] Display full file path in MI style disassembly listing

["Andrew Burgess" <aburgess@broadcom.com>]

On 18/10/2012 7:48 AM, Jan Kratochvil wrote:
> On Wed, 17 Oct 2012 20:13:40 +0200, Pedro Alves wrote:
>> On 10/05/2012 01:43 PM, Jan Kratochvil wrote:
>>> On Thu, 04 Oct 2012 18:09:28 +0200, Andrew Burgess wrote:
>>>> The patch below tries to use the fullname when it can, and falls back to the
>>>> shorter name if it can't figure out the full name.
>>>
>>> FYI this is a variant of not yet checked in more featured pathset:
>>> [patch] GDB 7.2: new feature for "backtrace" that cuts path to file (remain filename)
>>
>> I'm not sure I understand the relation between the patches.

I agree that though both patches relate to display of paths they are not
directly related.

I took a look at the original patch.  I it changes one place (in
backtrace) where we display symtab->filename.  There are several places
where we display symtab->filename, including the one I changed.

Either, (a) we plan to merge the original patch almost as is, in which
case it only changes the backtrace code, leaving my patch free to be
applied, or (b) we plan to extend the original patch to cover more/all
of the places we display symtab->filename, in which case, we'd have to
consider each of those places in turn and make a suitable change.

If (a) then my patch could go in, if (b) then it doesn't feel like my
patch changes things that much, I certainly don't add any new functions
or anything like that, that would make doing task (b) any harder later on.

>>                                                              I think we should
>> output a "fullname" field for MI, like we do for breakpoints.

I would be happy to take this approach as a compromise.

> Probably, it is true I do not know much how MI frontends display the data.

The frontend (eclipse in this case) wants to open the file in order to
display the contents.  Using just symtab->filename is not always
specific enough to identify a unique file.

I originally switched to only displaying the full path as this code is
only used for MI type output or when we fail to open the file, but I can
see that displaying the fullpath in addition might be cleaner.

Jan, if I post a patch that adds a fullpath would you be happy with that
as a solution?

Thanks,
Andrew








> 
> 
> Thanks,
> Jan
> 
> 
>