From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1p5iNK-0007US-FE for mharc-grub-devel@gnu.org; Thu, 15 Dec 2022 02:09:50 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p5iNI-0007U0-HF for grub-devel@gnu.org; Thu, 15 Dec 2022 02:09:48 -0500 Received: from mail-qt1-x82f.google.com ([2607:f8b0:4864:20::82f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p5iNG-00082g-0r for grub-devel@gnu.org; Thu, 15 Dec 2022 02:09:48 -0500 Received: by mail-qt1-x82f.google.com with SMTP id z12so4499276qtv.5 for ; Wed, 14 Dec 2022 23:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficientek-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=lrBbhpBLpmpZD6oSyFD9P8aSJvCY+3ZmgUPUyBRI80w=; b=RZnkQc5/nyPTzVI3dnALjQPK6AMAs+gtlv/BMCwfcDH6h3zz6wvPl2g1unsbT6DiKE 3+pI9ComZb4lbnun1xodVQSpFsjKqgX6zI82YvJZCwY5xUtI269FNR3N37UkBcfL7i46 iasK6KQOuObx55bsoPtdfveFPHaZ/tzalGh/Ga0aI2bkmeYV1qn7C6fIZ8c+LTTmGka4 455WxPDVLPylO5S/slOShce7g3iEjG5g+LbNhFiRDztH6diV5y1pDLlZSRuQSr35l/2V hxQtjmXjDe1sFaoKZehIP1aYs8s3BrWTeB06wykk9lCF9SII1UbKVHGhER7lnyp7BbX6 o5ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lrBbhpBLpmpZD6oSyFD9P8aSJvCY+3ZmgUPUyBRI80w=; b=agATVjZ20jxj06Qal05yoqnKhiIp0/oduhfbU/rViU4Dr1ObolQnRIjrRm8c47MMrk l5TzL2n2selIa88MN5DkurvxCg3V5taElHg3qaly7Hpdf8kEmaFQerx4oZVq2LkROpIk dzwl8i32dg24XrG+Y/Fq8KVug19eAM8gADuiGk+F/54nmqJposzyaOFeH9WWhd6n5pi5 ON36e+NMbusdTd3NkK4L2rgosw126dieQZwVh/7+BMhCbmeCzKJQBWkpVe/PbvxkdESf KNqKSX9mu/PyjF+NL2kdZPtFwrAz1CcFhhnHk0Y5K2690WsbVzQq8p3aYvp9QTN1qrDZ rnKw== X-Gm-Message-State: ANoB5pn1ctc52u2dx/TFEJyl4NC5zAPrNZkGT+mS3nynGgo1ttheSRaW gAsGkaopfmQgOHG5PTdlkKV4mchn6lAbqe7h X-Google-Smtp-Source: AA0mqf7wEMQ+FEYY8sM+225SvhKF7L5rD6vrpOSzUuSRLtR4dR4jLhDB49BL8Qgqni4qBEYDT8ttOw== X-Received: by 2002:a05:622a:5da9:b0:3a8:28a4:c4be with SMTP id fu41-20020a05622a5da900b003a828a4c4bemr9398801qtb.0.1671088184903; Wed, 14 Dec 2022 23:09:44 -0800 (PST) Received: from crass-HP-ZBook-15-G2.lan ([37.218.244.251]) by smtp.gmail.com with ESMTPSA id fy16-20020a05622a5a1000b003a7ec97c882sm3125068qtb.6.2022.12.14.23.09.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Dec 2022 23:09:43 -0800 (PST) From: Glenn Washburn To: grub-devel@gnu.org, Daniel Kiper Cc: Glenn Washburn Subject: [PATCH v3 07/15] gdb: Add functions to make loading from dynamically positioned targets easier Date: Thu, 15 Dec 2022 01:07:42 -0600 Message-Id: <20221215070750.102591-8-development@efficientek.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221215070750.102591-1-development@efficientek.com> References: <20221215070750.102591-1-development@efficientek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2607:f8b0:4864:20::82f; envelope-from=development@efficientek.com; helo=mail-qt1-x82f.google.com X-Spam_score_int: 14 X-Spam_score: 1.4 X-Spam_bar: + X-Spam_report: (1.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2022 07:09:48 -0000 Many targets, such as EFI, load GRUB at addresses that are determined at runtime. So the load addresses in kernel.exec will almost certainly be wrong. Given the address of the start of the text segment, these functions will tell GDB to load the symbols at the proper locations. It is left up to the user to determine how to get the text address. Signed-off-by: Glenn Washburn --- grub-core/Makefile.core.def | 6 ++++ grub-core/gdb_grub.in | 27 ++++++++++++++++ grub-core/gdb_helper.sh.in | 62 +++++++++++++++++++++++++++++++++++++ 3 files changed, 95 insertions(+) create mode 100644 grub-core/gdb_helper.sh.in diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def index 95942fc8c9..253b9b1e47 100644 --- a/grub-core/Makefile.core.def +++ b/grub-core/Makefile.core.def @@ -24,6 +24,12 @@ transform_data = { common = gmodule.pl.in; }; +transform_data = { + installdir = platform; + name = gdb_helper.sh; + common = gdb_helper.sh.in; +}; + transform_data = { installdir = platform; name = gdb_grub; diff --git a/grub-core/gdb_grub.in b/grub-core/gdb_grub.in index 521e3ae6ce..7891c6c07f 100644 --- a/grub-core/gdb_grub.in +++ b/grub-core/gdb_grub.in @@ -9,6 +9,33 @@ ### Lubomir Kundrak ### +define dynamic_load_kernel_exec_symbols + shell rm -f .remove-kernel.exec.symfile.gdb + shell sh gdb_helper.sh gen_kernel_exec_loadsym $arg0 >.kernel.exec.loadsym.gdb + source .kernel.exec.loadsym.gdb +end +document dynamic_load_kernel_exec_symbols + Load debugging symbols from kernel.exec given the address of the + .text segment of the UEFI binary in memory. +end + +define dynamic_load_symbols + dynamic_load_kernel_exec_symbols $arg0 + + # We may have been very late to loading the kernel.exec symbols and + # and modules may already be loaded. So load symbols for any already + # loaded. + load_all_modules + + runtime_load_module +end +document dynamic_load_symbols + Load debugging symbols from kernel.exec and any loaded modules given + the address of the .text segment of the UEFI binary in memory. Also + setup session to automatically load module symbols for modules loaded + in the future. +end + # Add section numbers and addresses to .segments.tmp define dump_module_sections_helper set $mod = $arg0 diff --git a/grub-core/gdb_helper.sh.in b/grub-core/gdb_helper.sh.in new file mode 100644 index 0000000000..b37d5adfc2 --- /dev/null +++ b/grub-core/gdb_helper.sh.in @@ -0,0 +1,62 @@ +### +### Helper functions for GRUB's GDB script. +### + +alignup() { + PAD=1 + if [ "$(($1%$2))" -eq 0 ]; then + PAD=0 + fi + printf "0x%x\n" "$(((($1/$2)+$PAD)*$2))" +} + +exp() { + BASE=${1%%\*\**} + EXP=${1##*\*\*} + RES=1 + while [ "$EXP" -gt 0 ]; do + RES=$(($RES*$BASE)) + EXP=$(($EXP - 1)) + done + echo $RES +} + +# Loading symbols is complicated by the fact that kernel.exec is an ELF +# ELF binary, but the UEFI runtime is PE32+. All the data sections of +# the ELF binary are concatenated (accounting for ELF section alignment) +# and put into one .data section in the PE32+ runtime image. So given +# the load address of the .data PE32+ section we can determine the +# addresses each ELF data section maps to. The UEFI application is +# loaded into memory just as it is laid out in the file. It is not +# assumed that the binary is available, but it is known that the .text +# section directly precedes the .data section and that .data is EFI +# page aligned. Using this, the .data offset from .text can be found. +gen_kernel_exec_loadsym() { + PE_SECTION_ALIGN=$((1<<12)) + PE_TEXT=$1 + TSIZE=$((0x$(objdump -h kernel.exec | grep -E " \.text\b" | \ + (read _ _ SIZE _; echo $SIZE)))) + PE_DATA_OFF=$(printf "0x%x" $(($(alignup ${TSIZE} ${PE_SECTION_ALIGN})))) + + printf "add-symbol-file kernel.exec ${PE_TEXT}" + objdump -h kernel.exec | tail -n +6 | \ + while read IDX NAME SIZE _ _ OFFSET ALIGN; do + read FLAGS + if [ -n "$FLAGS" ] && [ -z "${FLAGS%%*DATA*}" -o "$NAME" = .bss ]; then + OFF=$(alignup ${OFF:-0} $(exp $ALIGN)) + printf " -s $NAME (${PE_TEXT}+${PE_DATA_OFF}+0x%x)" "$OFF" + OFF=$((${OFF} + 0x${SIZE})) + fi + done +} + +if type "$1" 2>/dev/null | grep -q 'is a shell function'; then + if [ "x${GRUB_GDB_TRACE}" = "xy" ]; then + exec 2>>gdb_helper.trace + set -x + fi + + "$@" +else + exit 1 +fi -- 2.34.1