Re: Stack segments for Aarch64
Luis Machado via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
Right, "maint info sections" would complement "info proc mapping", if you want to have the visibility of all the interacting pieces in exec, core file and memory. On 6/6/24 11:27, Phil Phil wrote: > Would you suggest that the output of maintenance info sections is more "complete" if you want to see all mapped memory regions? > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* Luis Machado <[email protected]> > *Sent:* Thursday, June 6, 2024 10:15 AM > *To:* Phil Phil <[email protected]>; [email protected] <[email protected]> > *Subject:* Re: Stack segments for Aarch64 > > On 6/6/24 10:57, Phil Phil wrote: >> Should the stack segment still be there though? I compared a stackpointer to the memory areas from info proc mappings and I can't find a match. > > You'll likely find it in a core file section instead: maint info sections. > > For me: > > [28] 0xfffffffdf000->0x1000000000000 at 0x00191350: load13 ALLOC LOAD HAS_CONTENTS > > Does that help? GDB will look things up in the core file instead of memory, which is probably > why the way it displays things is slightly different. > > It could be improved I suppose. > >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> *From:* Luis Machado <[email protected]> >> *Sent:* Thursday, June 6, 2024 9:41 AM >> *To:* Phil Phil <[email protected]>; [email protected] <[email protected]> >> *Subject:* Re: Stack segments for Aarch64 >> >> Hi, >> >> On 6/6/24 10:33, Phil Phil wrote: >>> GDB 12.1 coredump post mortem coredump debugging on an x64 Linux desktop. I do not see a perms column in info proc mappings. >>> >> >> Ah, so it is corefile debugging. Checking on my end, I don't see the permissions column either. Now it escapes me if we have any >> special reason for that or if it is just an oversight somewhere. As for the stack marker, I suppose we lose that reference >> when the corefile is generated. That reference comes from /proc/<pid>/maps when we do "info proc mapping". >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >>> *From:* Luis Machado <[email protected]> >>> *Sent:* Thursday, June 6, 2024 9:23 AM >>> *To:* Phil Phil <[email protected]>; [email protected] <[email protected]> >>> *Subject:* Re: Stack segments for Aarch64 >>> >>> Hi, >>> >>> On 6/6/24 10:17, Phil Phil via Gdb wrote: >>>> Greetings, >>>> >>>> I'm trying get some memory info on an Aarch64 for a coredump. The aarch64 gdb produces this output for info proc mappings >>>> >>>> Start Addr End Addr Size Offset objfile >>>> 0x557ead9000 0x5582dee000 0x4315000 0x0 /usr/bin/myproc >>>> 0x5582dfe000 0x5582f0a000 0x10c000 0x4315000 /usr/bin/myproc >>>> 0x5582f0a000 0x5582f24000 0x1a000 0x4421000 /usr/bin/myproc >>>> >>>> I'm missing at least two things here compared to the x64 output: >>>> >>>> >>>> * >>>> No read/write permissions >>>> * >>>> Stack segments are not shown. >>>> >>>> Any ideas on how to make these two things visible on Aarch64? >>>> >>>> Regards >>> >>> What aarch64 debugging setup do you have? Versions etc? Remote? >>> >>> For me, running native gdb on aarch64: >>> >>> process 1681741 >>> Mapped address spaces: >>> >>> Start Addr End Addr Size Offset Perms objfile >>> 0xaaaaaaaa0000 0xaaaaac3c6000 0x1926000 0x0 r-xp /home/ubuntu/work/build/binutils-gdb-master/gdb/gdb >>> 0xaaaaac3d5000 0xaaaaacd2a000 0x955000 0x1925000 r--p /home/ubuntu/work/build/binutils-gdb-master/gdb/gdb >>> 0xaaaaacfc6000 0xaaaaad069000 0xa3000 0x0 rw-p [heap] >>> ... >>> 0xfffffffdf000 0x1000000000000 0x21000 0x0 rw-p [stack] >> >