Memory Map

IRC, freenode, #hurd, 2010-06

<jkoenig> is there a way to get gdb to map addresses as required when
debugging mach with qemu ?
<jkoenig> I can examine the data if I manually map the addresses th
0xc0000000 but maybe there's an easier way...
<youpi> jkoenig: I haven't found a way
<youpi> I'm mostly using the internal kdb

IRC, freenode, #hurd, 2011-07-14

<mcsim> Hello. I have problem with debugging gnumach. I set 2 brakepoints
in file i386/i386at/model_dep.c on functions gdt_init and idt_init. Then
I start qemu with patched gnumach kernel and stop at gdt_init. When I
enter command "continue" in gdb, qemu hangs. But when I go step by step,
using command "next", I freely reach idt_init. What can cause this
problem?
<braunr> hm
<braunr> not sure
<braunr> let me try
<braunr> mcsim: works for me :/
<mcsim> it works without my patch, but with it qemu hangs
<braunr> oh, i thought it worked when not using continue
<mcsim> with my patch I can reach idt_init only using next
<mcsim> and without all works fine
<braunr> mcsim: are you sure you correctly built it with debugging symbols
?
<mcsim> I've written in /etc/dpkg/buildflags.conf SET CFLAGS -g3 -O0
<braunr> hm
<braunr> i have internal kvm errors actually
<braunr> mcsim: do you use kvm ?
<braunr> mcsim: and why break on those functions ?
<braunr> i'm not sure the address space is already fine at this point
<mcsim> no. I don't have hardware virtualisation support.
<braunr> hm actually, you won't be able to use gdb
<braunr> i just remembered how gnumach is linked and mapped :/
<braunr> the addresses in the elf image are low addresses, matching the
image as it is loaded by the boot loader
<mcsim> I was wondering why qemu hangs.
<braunr> then the kernel uses segmentation to map itself at 2 (or 3
previously) GiB
<braunr> well, if the addresses are wrong, your breakpoints are wrong
<braunr> i even wonder how it can work when stepping
<braunr> i don't have the issue with x15 because of its linker script
<mcsim> Are there any ways of such debugging without qemu?
<braunr> i don't think so
<braunr> as antrik told you, the in kernel debugger needs many services
running before being usable
<braunr> you'll have to use printf, and there may be steps during bootstrap
when even that isn't available
<mcsim> So I need computer with hardware virtualisation?
<braunr> well, of course stepping works, since the breakpoints are relative
<braunr> no
<braunr> kvm has nothing to do with the problem
<braunr> it's just that the problem appears differently with kvm enabled
<mcsim> ok. thank you.
<braunr> good luck
<antrik> braunr: would it be hard to "fix" gnumach to avoid the
segmentation magic?...
<braunr> antrik: because of the linux drivers, it may
<antrik> or alternatively, implement something in GDB to deal with that?...
<braunr> antrik: i didn't study that part enough to know for sure
<antrik> uhm... why would the Linux drivers depend on that? does Linux also
do such magic?...
<braunr> well it should simply be a matter of shifting the address by a
fixed offset
<braunr> antrik: linux drivers rely on physical memory being allocated
through kmalloc
<braunr> so there must be a direct mapping between virtual kernel memory
and physical memory
<braunr> they don't specifically need that segmentation settings
<braunr> so if you remove the offset implemented through segmentation, you
have to replace it with page mapping
<braunr> and i don't know how much needs to be done for that
<braunr> you also need to link the kernel differently
<antrik> hm, OK
<antrik> so adding GDB support for the offset would probably be easier...
<braunr> yes
<braunr> but using the offset must only be done once segmentation is set up
<braunr> so you must break after gdt_init
<braunr> not on it
<braunr> mcsim: why do you break on these functions btw ?
<mcsim> I just wanted to find out why qemu hangs
<braunr> yes but why those ?
<mcsim> I found out that before gdt_init all workes fine, but after qemu
hangs. So idt_init is just the next function
<braunr> ok
<braunr> and does your patch change something to how segmentation is
initialized ?
<mcsim> now
<mcsim> no
<braunr> try to build it with the regular cflags
<braunr> i don't know if gnumach can work with -O0
<mcsim> I've tried. But all the same
<mcsim> Regular are -g -O2
<braunr> can you make your patch available ?
<mcsim> yes
<mcsim> it is available in gnumach repository at savannah
<mcsim> tree mplaneta/libbraunr/master
<antrik> well, if the segmentation stuff is the thing GDB has problems
with, I don't see how it can work without your patch...
<braunr> without ?
<antrik> well, the patch shouldn't affect the segmentation... so I don't
see how it can make a difference
<braunr> he said qemu hanged
<braunr> so let's not introduce gdb yet
<braunr> qemu can hang for other reasons
<antrik> oh, right, without GDB...
<antrik> though if that's what he meant, his statement was very misleading
at least

IRC, freenode, #hurd, 2014-02-24

<congzhang> hi, will grub load mach kernel to fix address? and which
address?
<congzhang> I want to use qemu gdb support to debug mach
<congzhang> need add-symble-file to right address
<youpi> congzhang: see objdump gnumach
<youpi> grub simply follows what's provided by the ELF format of the ELF
file
<nalaginrut> I think it's default value of _start in ELF, right?
<nalaginrut> hmm...the actual entry point should plus the size of
multi_boot header, at least 0xc...
<congzhang> youpi: I try that, but not works
<congzhang> I start qemu with -s
<congzhang> the /bin/console was very easy to cause black death, and I want
to use gdb to check whether the mach is death
<congzhang> I will try again later
<congzhang> Anyone know some tutorial to debug mach with qemu?
<nalaginrut> for better debug, I suggest bochs
<nalaginrut> although it's slower
<congzhang> nalaginrut: maybe it's my problem, I did not do the right thing
<congzhang> qemu with kvm was great.
<nalaginrut> qemu with kvm is cool to run, but not so cool for debug kernel
<nalaginrut> anyway, it's personal taste
<nalaginrut> you may use gdb for that
<nalaginrut> for bochs, you don't have to use external debugger
<congzhang> thanks for explain

Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled GNU Free Documentation
License.