Re: [PATCH] AArch64 pauth: Indicate unmasked addresses in backtrace

[Alan Hayward <Alan.Hayward@arm.com>]

> On 17 Jul 2019, at 17:41, Pedro Alves <palves@redhat.com> wrote:
> 
> On 7/17/19 5:07 PM, Alan Hayward wrote:
> 
>>> I almost suggested the same, but didn't when I realized that we
>>> don't always print the addresses:
>>> 
>>> (top-gdb) bt
>>> #0  gdb_main (args=0x7fffffffd3a0) at src/gdb/main.c:1186
>>> #1  0x0000000000469a7e in main (argc=1, argv=0x7fffffffd4a8) at src/gdb/gdb.c:32
>>> 
>> 
>> What’s the reason for that? Surely we always know the address of a function
>> in the backtrace? Can it happen in the middle of a backtrace?
> 
> "It always worked that way", at least for me.
> 
> We show an address if the PC is pointing to the middle
> of a line, or we don't have debug info.  If pointing at a line
> exactly, then we show no address.
> 
> (gdb) frame
> #0  main (argc=1, argv=0x7fffffffd4a8) at src/gdb/gdb.c:29
> 29        args.argc = argc;
> (gdb) si
> 0x0000000000469a5f      29        args.argc = argc;
> (gdb) frame
> #0  0x0000000000469a5f in main (argc=1, argv=0x7fffffffd4a8) at src/gdb/gdb.c:29
> 29        args.argc = argc;
> 
> 
> Same logic for when displaying the frame where a program stops, when
> stepping, ctrl-c, breakpoint hits, etc.
> 
> Breakpoint 5, main (argc=1, argv=0x7fffffffd4a8) at src/gdb/gdb.c:28
>               ^^^^
> 28        memset (&args, 0, sizeof args);
> (gdb) p /x $pc
> $1 = 0x469a46
> (top-gdb) del
> Delete all breakpoints? (y or n) y
> (top-gdb) r
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
> Starting program: build/gdb/gdb 
> Breakpoint 6, 0x0000000000469a4a in main (argc=1, argv=0x7fffffffd4a8) at src/gdb/gdb.c:28
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^
> 28        memset (&args, 0, sizeof args);


Excellent, thanks.

> 
>> 
>> 
>>> But if you do want to align the addresses, you could do that by
>>> specifying a width for the "addr" column.
>> 
>>> If "[U]" is rare, given no column
>>> headers, the spaces may look a bit odd, though.
>> 
>> In general, it depends how a binary/library was compiled. But I’d expect a binary
>> to either have it in most functions or none.
>> 
>> Should be easy enough to remove the extra spaces if the system doesn’t support PAC.
>> 
>> 
>>> Maybe you'd want to pre-compute
>>> the max column width by looking at the max number of frames that fit on a
>>> page, or something along those lines.
>>> 
>> 
>> hmmm... ok. I’ll see what I can do there.
> 
> If most functions have it, then I wouldn't bother trying to compute
> the max column width.
> 
> But then if most functions have it, I wonder what's the point of
> showing the marker, though.  :-)  Would it make sense to reverse
> the logic?
> 

I think it’s still better this way around. It indicates that PAC is being used.
You might, for example, be running 8.0 binaries on 8.3 system, which has then
linked against your libc etc which is using 8.3 PAC.
(You can also run 8.3 PAC on 8.0, as the relevant stuff will just turn into nops).


> Thanks,
> Pedro Alves