From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 3344838582AE for ; Mon, 18 Dec 2023 15:56:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3344838582AE Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3344838582AE Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702914964; cv=none; b=piNxn2jnIgxQE4hj3mBxNZUVkErGfBg5BxfnCSGATQLYIsSu80Bme+vdOEcpU34mvxBN8m8LGOjLwVafwC5h0KE3KVPUuRGMfpGeNj1/NdvkHxF7Fw2oGWkTNV/ADShTrVpJtY4vVaWWbDE2jg8Ot/d7dlfpY3D5QpSXbcwYIOw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702914964; c=relaxed/simple; bh=SKBkP0FYQ0TkDqOoyfZNEGsOuF1WjUPXiFvFbmkFL04=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=IQAJmUiGQ4ml/IyqcoarDMOiyUc79jRNE8LNX4Ot+eymcNonRiuSfzRLH7EO8F9SfCohpynvzRCkdxItFTjUkjqBux0qnfx6pFKY9oH9+iX8T9amGZyVzbrKvS9lVSM0ubXHmSYbq65XI2rLXomwEVXbyWNvCgukjXRKoTJ8oS8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702914960; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=61ptnJdLO3wPdbyPDTzwaUOeg+GUG2FKRc/Q19+ZJwc=; b=hFnjV0ahB13b7sc5+s9c7RC2batA7N+GVdhaNDkaYrRLQ4aAWhJvyZWJIDPR/Bp2HoeAZ/ 7nJPqct0zsonFoVYeN9R8+FLeboN5qxMpIX8mItZI9VUoWxrZ1+8vPatuqbqu538idz8eP Gm0aEa1gXhv6Iut4cXaLinpX3RFRDXU= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-486-jTvzOOzmPS-ASrSMfO0RxQ-1; Mon, 18 Dec 2023 10:55:58 -0500 X-MC-Unique: jTvzOOzmPS-ASrSMfO0RxQ-1 Received: by mail-ed1-f71.google.com with SMTP id 4fb4d7f45d1cf-54c882dcb76so3595273a12.0 for ; Mon, 18 Dec 2023 07:55:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702914957; x=1703519757; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:to:from:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=RpHmLTJsPIdbcyttWjwhL/P0jl6t0LDr6ZKxlmqlC7g=; b=hKA+90AAVtrrRoiiHhl/uD6bpazrxSci441vGexJzEZpAxNSibb2Eu3hN1EELZX3aG rBMg88l5RvRj2zFTJCWW3N3xpIOvgApkTf8VQ0Nmh42dYerp2G1hbaUcY/V6WQEsIA2+ TSpLOgC4Ukc+3DM6QmY9m+PRGzLe0llRTF2ptuREvC81yQ31tN2AQ8Ub04xVvb263IvO w2r4rmCRPkOX++QCwu1AFFrPctrHW4lpGM0ijMn33oKhMV4/iYXxqh06hhrBY+V4+wK7 VKU0+5Ac2y7Dza21z2b2rRJu7G8IxL6HCGg5Tc3fBXnSk40YYCBwWwgjfSUT/mKw68P5 gN7Q== X-Gm-Message-State: AOJu0Yz0rhIPk9L69SMnl9kuDDt8mrw8vsLdHFXGWUklHZO/x9Ov+mnY mawitF/5qheboc6wFgbYR0j+AeMtj6kuZU3etub4RzLZIDG0YpQWAgtGGUVQonQ+Knw2bpTymEj 5gVCZI2YZC/cjJiIa6DB/xuCYqRm1nw== X-Received: by 2002:a50:cd97:0:b0:553:d69:9059 with SMTP id p23-20020a50cd97000000b005530d699059mr3797607edi.4.1702914956408; Mon, 18 Dec 2023 07:55:56 -0800 (PST) X-Google-Smtp-Source: AGHT+IHo41fsGHsLzd98KeDesAnqfaFxPYC9k7SQh0skoSoJ3xbqDgPSGvu2LTiA9gAiYidiJ6S3Tg== X-Received: by 2002:a17:906:55:b0:a1b:7700:2c0b with SMTP id 21-20020a170906005500b00a1b77002c0bmr18225681ejg.19.1702914638819; Mon, 18 Dec 2023 07:50:38 -0800 (PST) Received: from localhost (105.226.159.143.dyn.plus.net. [143.159.226.105]) by smtp.gmail.com with ESMTPSA id th18-20020a1709078e1200b00a2300127f26sm7262051ejc.185.2023.12.18.07.50.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Dec 2023 07:50:38 -0800 (PST) From: Andrew Burgess To: Zeck S , gdb-patches@sourceware.org Subject: Re: [RFC][PATCH?] fixed some segfaults and bugs in mdebug support In-Reply-To: References: <20231211114252.451602-2-zeck654321@gmail.com> <87jzpkg7kh.fsf@redhat.com> Date: Mon, 18 Dec 2023 15:50:37 +0000 Message-ID: <87il4v4iia.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Zeck S writes: > I definitely would like to add some tests, or tweak some existing tests! > Just was not sure how normal that was, or if it would almost be viewed > "cheating" or something. I don't think it would be considered cheating. I'd just make sure to place a comment at the head of the file explaining that the test is deliberately simple in order to compile with XXX compiler and that changes should be made with care. This will pretty much guarantee nobody else will dare change the test's source code :) As Tom said, the mdebug stuff is not used much, so if you posted an updated patch without any tests, I'd be happy to approve it. It's your choice. Thanks, Andrew > I really wanted to get the test suite running, which is why I made the > qemu-user board. > And it has been very useful, but legitimately some of the tests just can'= t > pass (or sometimes even build) with this nasty old compiler and symbol > format combination. > If I can make a few new tests I can work around all of this with relative > ease. > > I'll address everything else as well! > > I'm tempted to make some kind of container for making running tests with > this setup easier. > It's all a bit ridiculous, wrapping an old compiler and a modern linker i= n > a bash script, then the compiler runs in an emulator, the built executabl= e > runs in another emulator... > If I do that I'll make it public somewhere. > > Thanks for the feedback. I know this is a weird old format, but it is > actually becoming slightly more relevant again with the N64 game > decompilation projects. > > On Mon, Dec 11, 2023 at 8:03=E2=80=AFAM Andrew Burgess wrote: > >> Zeck S writes: >> >> > I'm not quite sure what to do. >> > I have done some testing using the qemu-mips board I made. >> > There are a lot of limitations I'm running into. >> > I can just run as much of the testsuite as I can and see what happens. >> > >> > >> > Here are the main problems: >> > 1. IDO only supports ansi c. This is a problem for some headers in gli= bc >> which use c99. >> > 2. Test code sometimes has GCC features in them like asm() >> > 3. Test expectations sometimes assume features from nicer formats like >> DWARF. >> > >> > I knew I probably couldn't get standard library stuff working. >> > Even if I hack past the C99 issues (variadic macros), >> > there's also problems >> > with compiler specific files like stddef.h. >> > >> > I started testing by just running gdb.base/info-types-c.exp alone, >> > since I knew I fixed bugs in that area, and the test didn't use stdio.= h. >> > Found that the .c file used asm() which IDO doesn't support. >> > Commented that code out, ran the test. Failed. >> > Fixed a segfault that had been introduced since I started this project= . >> > Still failed. >> > Fixed some typedef handling to get closer to the expected output. >> > However, the expected output includes line numbers for types. >> > mdebug format doesn't include line information for types. >> > There are also differences in output stemming from >> > mdebug assuming the debugger knows size information etc about "basic" >> > types, unlike dwarf, which includes information about them. >> > >> > So at this point, I realize, I've modified the .c file for the test >> > which already seems not great, and I realize due to limitations of >> mdebug, >> > I can't ever make the test pass. >> > Not sure how to demonstrate this as progress, but uh, it feels like >> > progress? >> >> So, I know nothing about targets that make use of ECOFF / mdebug format >> stuff, and I don't really have time to try setting up a test >> environment. >> >> I guess my expectation for at least some of these fixes would be that >> you could write a small sample program that does compile with your >> compiler, and then a .exp file which triggers the right GDB commands to >> expose the bug. >> >> From what you've said, it doesn't sound like the existing test framework >> actually has problems invoking the compiler and running the test, it's >> just that the test has too many DWARF/ISO-C assumptions within. >> >> Personally, I'm a huge fan of writing tests, I think it is worth the >> effort in the long run, so I think it would be worth your time to try >> and write some new tests for these issues. >> >> That said, given the nature of these fixes and the difficulties you're >> experiencing, if you don't feel that's possible, I'm not going to oppose >> merging these fixes without tests... >> >> ... but I do have a couple of style issues that would need fixing first, >> see inline below: >> >> > >> > >> > For the curious, this is the bash script I wrapped IDO with. >> > stderr is directed to dev null, because qemu-irix puts some non fatal >> > errors there, which confuses the test runner. >> > Put the script in a directory in PATH. >> > Passing an executable path as CC_FOR_TARGET does not work. >> > It must be the name of a file in PATH. >> > >> > #!/bin/sh >> > >> > echo "$@" >> theargs >> > >> > for arg do >> > if [ "$arg" =3D "-static" ] >> > then >> > link=3D1 >> > fi >> > done >> > >> > if [ "$link" =3D 1 ] >> > then >> > mips-unknown-linux-gnu-gcc "$@" >> > else >> > for arg do >> > shift >> > [ "$arg" =3D "-fdiagnostics-color=3Dnever" ] && continue >> > [ "$arg" =3D "-g" ] && continue >> > set -- "$@" "$arg" >> > done >> > >> > /path/to/qemu-irix -L /path/to/ido/ido7.1_compiler >> /path/to/ido/ido7.1_compiler/usr/bin/cc -Xcpluscomm -nostdlib -nostdinc >> -mips2 -g2 "$@" 2>/dev/null >> > fi >> > >> > >> > --- >> > gdb/mdebugread.c | 89 ++++++++++++++++++++++++++++-------------------= - >> > 1 file changed, 52 insertions(+), 37 deletions(-) >> > >> > diff --git a/gdb/mdebugread.c b/gdb/mdebugread.c >> > index cd6638224e7..191932e91cd 100644 >> > --- a/gdb/mdebugread.c >> > +++ b/gdb/mdebugread.c >> > @@ -237,7 +237,7 @@ static struct type *new_type (char *); >> > enum block_type { FUNCTION_BLOCK, NON_FUNCTION_BLOCK }; >> > >> > static struct block *new_block (struct objfile *objfile, >> > - enum block_type, enum language); >> > + enum block_type, enum language, bool >> isGlobal); >> >> GDB style is for snake_case rather than camelCase, so: >> s/isGlobal/is_global/ throughout. >> >> > >> > static struct compunit_symtab *new_symtab (const char *, int, struct >> objfile *); >> > >> > @@ -246,7 +246,7 @@ static struct linetable *new_linetable (int); >> > static struct blockvector *new_bvect (int); >> > >> > static struct type *parse_type (int, union aux_ext *, unsigned int, i= nt >> *, >> > - int, const char *); >> > + int, const char *, bool); >> > >> > static struct symbol *mylookup_symbol (const char *, const struct blo= ck >> *, >> > domain_enum, enum address_class); >> > @@ -572,7 +572,7 @@ add_data_symbol (SYMR *sh, union aux_ext *ax, int >> bigend, >> > || sh->sc =3D=3D scNil || sh->index =3D=3D indexNil) >> > s->set_type (builtin_type (objfile)->nodebug_data_symbol); >> > else >> > - s->set_type (parse_type (cur_fd, ax, sh->index, 0, bigend, name))= ; >> > + s->set_type (parse_type (cur_fd, ax, sh->index, 0, bigend, name, >> false)); >> > /* Value of a data symbol is its memory address. */ >> > } >> > >> > @@ -705,7 +705,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char >> *ext_sh, int bigend, >> > break; >> > } >> > s->set_value_longest (svalue); >> > - s->set_type (parse_type (cur_fd, ax, sh->index, 0, bigend, name= )); >> > + s->set_type (parse_type (cur_fd, ax, sh->index, 0, bigend, name= , >> false)); >> > add_symbol (s, top_stack->cur_st, top_stack->cur_block); >> > break; >> > >> > @@ -761,7 +761,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char >> *ext_sh, int bigend, >> > t =3D builtin_type (objfile)->builtin_int; >> > else >> > { >> > - t =3D parse_type (cur_fd, ax, sh->index + 1, 0, bigend, name); >> > + t =3D parse_type (cur_fd, ax, sh->index + 1, 0, bigend, name, >> false); >> > if (strcmp (name, "malloc") =3D=3D 0 >> > && t->code () =3D=3D TYPE_CODE_VOID) >> > { >> > @@ -805,7 +805,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char >> *ext_sh, int bigend, >> > s->type ()->set_is_prototyped (true); >> > >> > /* Create and enter a new lexical context. */ >> > - b =3D new_block (objfile, FUNCTION_BLOCK, s->language ()); >> > + b =3D new_block (objfile, FUNCTION_BLOCK, s->language (), false= ); >> > s->set_value_block (b); >> > b->set_function (s); >> > b->set_start (sh->value); >> > @@ -1135,7 +1135,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char >> *ext_sh, int bigend, >> > } >> > >> > top_stack->blocktype =3D stBlock; >> > - b =3D new_block (objfile, NON_FUNCTION_BLOCK, psymtab_language)= ; >> > + b =3D new_block (objfile, NON_FUNCTION_BLOCK, psymtab_language, >> false); >> > b->set_start (sh->value + top_stack->procadr); >> > b->set_superblock (top_stack->cur_block); >> > top_stack->cur_block =3D b; >> > @@ -1247,7 +1247,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char >> *ext_sh, int bigend, >> > f->set_loc_bitpos (sh->value); >> > bitsize =3D 0; >> > f->set_type (parse_type (cur_fd, ax, sh->index, &bitsize, bigend= , >> > - name)); >> > + name, false)); >> > f->set_bitsize (bitsize); >> > } >> > break; >> > @@ -1269,7 +1269,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char >> *ext_sh, int bigend, >> > pend =3D is_pending_symbol (cur_fdr, ext_sh); >> > if (pend =3D=3D NULL) >> > { >> > - t =3D parse_type (cur_fd, ax, sh->index, NULL, bigend, name); >> > + t =3D parse_type (cur_fd, ax, sh->index, NULL, bigend, name, t= rue); >> > add_pending (cur_fdr, ext_sh, t); >> > } >> > else >> > @@ -1382,7 +1382,7 @@ basic_type (int bt, struct objfile *objfile) >> > if (map_bt[bt]) >> > return map_bt[bt]; >> > >> > - type_allocator alloc (objfile, get_current_subfile ()->language); >> > + type_allocator alloc (objfile, psymtab_language); >> >> With fixes like this, it can (I think) be useful to mention the commit >> that is being fixed, in this case 76fc0f62138e. Wouldn't be much, I'd >> just say: >> >> Commit 76fc0f62138e added calls to 'get_current_subfile ()->language', >> but at the time this was known to be a bit of a guess, and untested. >> We should actually have used 'psymtab_language' because .... >> >> Then, if in the future, someone looks at your patch and wonders why was >> this change made? There's a super quick way that can find the history >> of this code, and understand the original change, and your update. >> >> > >> > switch (bt) >> > { >> > @@ -1514,7 +1514,7 @@ basic_type (int bt, struct objfile *objfile) >> > >> > static struct type * >> > parse_type (int fd, union aux_ext *ax, unsigned int aux_index, int *b= s, >> > - int bigend, const char *sym_name) >> > + int bigend, const char *sym_name, bool isStTypedef) >> >> Switch to snake_case for isStTypedef. >> >> > { >> > TIR t[1]; >> > struct type *tp =3D 0; >> > @@ -1571,7 +1571,7 @@ parse_type (int fd, union aux_ext *ax, unsigned >> int aux_index, int *bs, >> > } >> > } >> > >> > - type_allocator alloc (mdebugread_objfile, get_current_subfile >> ()->language); >> > + type_allocator alloc (mdebugread_objfile, psymtab_language); >> > >> > /* Move on to next aux. */ >> > ax++; >> > @@ -1628,7 +1628,7 @@ parse_type (int fd, union aux_ext *ax, unsigned >> int aux_index, int *bs, >> > xref_fh =3D get_rfd (fd, rf); >> > xref_fd =3D xref_fh - debug_info->fdr; >> > tp =3D parse_type (xref_fd, debug_info->external_aux + >> xref_fh->iauxBase, >> > - rn->index, NULL, xref_fh->fBigendian, sym_name); >> > + rn->index, NULL, xref_fh->fBigendian, sym_name, fals= e); >> > } >> > >> > /* All these types really point to some (common) MIPS type >> > @@ -1785,6 +1785,13 @@ parse_type (int fd, union aux_ext *ax, unsigned >> int aux_index, int *bs, >> > if (t->continued) >> > complaint (_("illegal TIR continued for %s"), sym_name); >> > >> > + if (isStTypedef) >> > + { >> > + struct type *wrap =3D alloc.new_type (TYPE_CODE_TYPEDEF, 0, >> sym_name); >> > + wrap->set_target_type(tp); >> > + tp =3D wrap; >> > + } >> >> GNU style indents the '{' and '}', this should look like: >> >> if (isStTypedef) >> { >> struct type *wrap =3D alloc.new_type (TYPE_CODE_TYPEDEF, 0, sym_na= me); >> wrap->set_target_type(tp); >> tp =3D wrap; >> } >> >> > + >> > return tp; >> > } >> > >> > @@ -1839,7 +1846,7 @@ upgrade_type (int fd, struct type **tpp, int tq, >> union aux_ext *ax, int bigend, >> > >> > indx =3D parse_type (fh - debug_info->fdr, >> > debug_info->external_aux + fh->iauxBase, >> > - id, NULL, bigend, sym_name); >> > + id, NULL, bigend, sym_name, false); >> > >> > /* The bounds type should be an integer type, but might be >> anything >> > else due to corrupt aux entries. */ >> > @@ -2154,8 +2161,7 @@ parse_external (EXTR *es, int bigend, const >> section_offsets §ion_offsets, >> > with that and do not need to reorder our linetables. */ >> > >> > static void >> > -parse_lines (FDR *fh, PDR *pr, struct linetable *lt, int maxlines, >> > - CORE_ADDR lowest_pdr_addr) >> > +parse_lines (FDR *fh, PDR *pr, struct linetable *lt, int maxlines) >> >> As above, this seems to be reverting parts of 1acc9dca423f78e4, it would >> be great to more of an explanation for why that commit was wrong. >> >> Remember, someone thought that commit was correct once. You're looking >> at their code and thinking they got it wrong. What's to stop someone >> looking at your code and thinking _you_ got it wrong? >> >> Hopefully, what stops that is that you add more details in the commit >> message, along with a link to the previous commit. >> >> > { >> > unsigned char *base; >> > int j, k; >> > @@ -2169,7 +2175,6 @@ parse_lines (FDR *fh, PDR *pr, struct linetable >> *lt, int maxlines, >> > for (j =3D 0; j < fh->cpd; j++, pr++) >> > { >> > CORE_ADDR l; >> > - CORE_ADDR adr; >> > unsigned char *halt; >> > >> > /* No code for this one. */ >> > @@ -2186,9 +2191,7 @@ parse_lines (FDR *fh, PDR *pr, struct linetable >> *lt, int maxlines, >> > halt =3D base + fh->cbLine; >> > base +=3D pr->cbLineOffset; >> > >> > - adr =3D pr->adr - lowest_pdr_addr; >> > - >> > - l =3D adr >> 2; /* in words */ >> > + l =3D pr->adr >> 2; /* in words */ >> > for (lineno =3D pr->lnLow; base < halt;) >> > { >> > count =3D *base & 0x0f; >> > @@ -4053,6 +4056,14 @@ mdebug_expand_psymtab (legacy_psymtab *pst, >> struct objfile *objfile) >> > { >> > (*swap_pdr_in) (cur_bfd, pdr_ptr, pdr_in); >> > >> > + char *sym_ptr =3D (char *)(debug_info->external_sym) + >> > + (fh->isymBase + pdr_in->isym) * external_sym_size; >> >> The layout seems wrong here. There should for sure be a single space >> after '(char *)', and the '+' should be at the start of the new line >> rather than the end of the previous line. >> >> Additionally, we usually wrap expressions like this within '( ... )' to >> force editors to align things better. Turns out that this pattern of >> code is repeated lots in this file. Search for: '* external_sym_size' >> and you'll find lots of example for how to align this code. I'd go >> with: >> >> char *sym_ptr =3D ((char *) debug_info->external_sym >> + (fh->isymBase + pdr_in->isym) >> * external_sym_size); >> >> maybe? >> >> > + >> > + SYMR sh; >> > + (*swap_sym_in) (cur_bfd, sym_ptr, &sh); >> > + >> > + pdr_in->adr =3D sh.value; >> > + >> > /* Determine lowest PDR address, the PDRs are not always >> > sorted. */ >> > if (pdr_in =3D=3D pr_block.data ()) >> > @@ -4154,16 +4165,16 @@ mdebug_expand_psymtab (legacy_psymtab *pst, >> struct objfile *objfile) >> > { >> > (*swap_pdr_in) (cur_bfd, pdr_ptr, pdr_in); >> > >> > - /* Determine lowest PDR address, the PDRs are not alwa= ys >> > - sorted. */ >> > - if (pdr_in =3D=3D pr_block.data ()) >> > - lowest_pdr_addr =3D pdr_in->adr; >> > - else if (pdr_in->adr < lowest_pdr_addr) >> > - lowest_pdr_addr =3D pdr_in->adr; >> > + sym_ptr =3D (char *)(debug_info->external_sym) + >> > + (fh->isymBase + pdr_in->isym) * external_sym_size= ; >> >> Similar layout issues to above. >> >> > + >> > + SYMR sh; >> > + (*swap_sym_in) (cur_bfd, sym_ptr, &sh); >> > + >> > + pdr_in->adr =3D sh.value; >> >> These lines are all indented using only spaces. GDB (unfortunately) >> uses a hybrid tab and space approach for indentation. If you 'git diff' >> and look at this file, git _should_ highlight the whitespace issues for >> you -- we have a .gitattributes file in the binutils-gdb root that asks >> for whitespace issues to be highlighted. >> >> > } >> > >> > - parse_lines (fh, pr_block.data (), lines, maxlines, >> > - lowest_pdr_addr); >> > + parse_lines (fh, pr_block.data (), lines, maxlines); >> > if (lines->nitems < fh->cline) >> > lines =3D shrink_linetable (lines); >> > >> > @@ -4291,7 +4302,7 @@ cross_ref (int fd, union aux_ext *ax, struct typ= e >> **tpp, >> > rf =3D rn->rfd; >> > } >> > >> > - type_allocator alloc (mdebugread_objfile, get_current_subfile >> ()->language); >> > + type_allocator alloc (mdebugread_objfile, psymtab_language); >> > >> > /* mips cc uses a rf of -1 for opaque struct definitions. >> > Set TYPE_STUB for these types so that check_typedef will >> > @@ -4412,7 +4423,8 @@ cross_ref (int fd, union aux_ext *ax, struct typ= e >> **tpp, >> > sh.index, >> > NULL, >> > fh->fBigendian, >> > - debug_info->ss + fh->issBase + sh.iss); >> > + debug_info->ss + fh->issBase + sh.iss, >> > + sh.st =3D=3D stTypedef); >> > add_pending (fh, esh, *tpp); >> > break; >> > >> > @@ -4438,7 +4450,8 @@ cross_ref (int fd, union aux_ext *ax, struct typ= e >> **tpp, >> > sh.index, >> > NULL, >> > fh->fBigendian, >> > - debug_info->ss + fh->issBase + sh.iss); >> > + debug_info->ss + fh->issBase + sh.iss, >> > + true); >> > } >> > else >> > { >> > @@ -4542,6 +4555,7 @@ add_line (struct linetable *lt, int lineno, >> CORE_ADDR adr, int last) >> > return lineno; >> > >> > lt->item[lt->nitems].line =3D lineno; >> > + lt->item[lt->nitems].is_stmt =3D 1; >> > lt->item[lt->nitems++].set_unrelocated_pc (unrelocated_addr (adr << >> 2)); >> > return lineno; >> > } >> > @@ -4634,9 +4648,10 @@ new_symtab (const char *name, int maxlines, >> struct objfile *objfile) >> > >> > /* All symtabs must have at least two blocks. */ >> > bv =3D new_bvect (2); >> > - bv->set_block (GLOBAL_BLOCK, new_block (objfile, NON_FUNCTION_BLOCK= , >> lang)); >> > - bv->set_block (STATIC_BLOCK, new_block (objfile, NON_FUNCTION_BLOCK= , >> lang)); >> > + bv->set_block (GLOBAL_BLOCK, new_block (objfile, NON_FUNCTION_BLOCK= , >> lang, true)); >> > + bv->set_block (STATIC_BLOCK, new_block (objfile, NON_FUNCTION_BLOCK= , >> lang, false)); >> > bv->static_block ()->set_superblock (bv->global_block ()); >> > + bv->global_block ()->set_compunit_symtab(cust); >> > cust->set_blockvector (bv); >> > >> > cust->set_debugformat ("ECOFF"); >> > @@ -4723,9 +4738,10 @@ new_bvect (int nblocks) >> > >> > static struct block * >> > new_block (struct objfile *objfile, enum block_type type, >> > - enum language language) >> > + enum language language, bool isGlobal) >> > { >> > - struct block *retval =3D new (&objfile->objfile_obstack) block; >> > + struct block *retval =3D isGlobal ? new (&objfile->objfile_obstack) >> global_block >> > + : new (&objfile->objfile_obstack) block; >> >> By the time you've s/isGlobal/is_global/ I think you should format this >> as: >> >> struct block *retval =3D (is_global >> ? new (&objfile->objfile_obstack) global_block >> : new (&objfile->objfile_obstack) block); >> >> >> Thanks, >> Andrew >> >> >> > >> > if (type =3D=3D FUNCTION_BLOCK) >> > retval->set_multidict (mdict_create_linear_expandable (language))= ; >> > @@ -4754,8 +4770,7 @@ new_type (char *name) >> > { >> > struct type *t; >> > >> > - t =3D type_allocator (mdebugread_objfile, >> > - get_current_subfile ()->language).new_type (); >> > + t =3D type_allocator (mdebugread_objfile, psymtab_language).new_typ= e (); >> > t->set_name (name); >> > INIT_CPLUS_SPECIFIC (t); >> > return t; >> > -- >> > 2.41.0 >> >>