From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: "Peter.Schauer" Cc: gdb-patches@sourceware.cygnus.com, taylor@cygnus.com Subject: Re: [PATCH]: Make Sparc Target Multi-Arch Date: Tue, 02 May 2000 10:13:00 -0000 Message-id: <390F0C46.451B@cygnus.com> References: <200005021109.NAA12981@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-05/msg00030.html Peter.Schauer wrote: > > > I've also included in this patch the ability to do call-dummies > > using the AT_ENTRY_POINT method, rather than pushing instructions > > onto the stack (since that isn't allowed in 64-bit Solaris). > > Using AT_ENTRY_POINT will return bad results when calling a Sun cc compiled > function that returns a struct from within GDB. > > Sun cc generates code which checks the expected structure size against > the passed structure size (in the extra word after the call) and does not > copy to the result structure if the sizes don't match. > Below is the disassembly of a function returning a structure with size 16. Yuck! Well, I can't use ON_STACK, because (a) the stack section is protected against execution in Solaris/Sparc64, and (b) it's too far from the text section for an ordinary jump/call. What if I write the return struct size to the entry point address, following the trap instruction, and remove it when finished (like the trap instruction)? >From ezannoni@cygnus.com Tue May 02 13:10:00 2000 From: Elena Zannoni To: Elena Zannoni Cc: Jim Blandy , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] in_prologue() fix Date: Tue, 02 May 2000 13:10:00 -0000 Message-id: <14607.13887.744690.553862@kwikemart.cygnus.com> References: <14598.9829.764888.505476@kwikemart.cygnus.com> <14599.32044.511265.33190@kwikemart.cygnus.com> X-SW-Source: 2000-05/msg00031.html Content-length: 2507 Ok, just to follow up on this: after personal e-mail/phone exchanges with Jim, we agreed on a different solution. So this patch is withdrawn. Elena Elena Zannoni writes: > Jim Blandy writes: > > > > > It may be that the real fix is to make ecs->stop_func_start be the > > > beginning of the function where the adjusted stop_pc is. However that > > > would require several changes to H.I.E. But in any event in_prologue() > > > is wrong for this particular case. > > > > My first question is, if HIE can find enough symbolic information to > > set ecs->stop_func_{name,start,end}, how come in_prologue can't find > > it? > > > > I am not sure I understand your question. in_prologue finds the start > and end of the function within which pc is (in the same way HIE does for > the wrong pc). Because of the way in_prologue works, the info found is > not compared with the input function address. Doing this would be > another way to fix the problem, but you would have to rewrite > in_prologue. What I am trying to say is that in_prologue takes 2 > inputs: a pc and a function start address. It has to determine if the > pc is within the prologue of the function starting at the address. In > this case it gets it wrong because it doesn't think about checking if pc > is within the function at all. > > > > In other words: your explanation implies that HIE has some way to find > > the function extent, but happens to be wrong because of > > DECR_PC_AFTER_BREAK lossage. But in_prologue knows the correct PC; > > why can't it use the same mechanism HIE used earlier to get the right > > answer? > > > > It does use the same mechanism (find_pc_partial_function) but it > doesn't check the results properly. > > > Also, aren't there other adverse consequences when > > ecs->stop_func_{name,start,end} are wrong? I think the HIE fix is the > > right thing. HIE is painful for me too, but otherwise, you'll just > > get another CR in a month. > > > > So I thought too. But in case of breakpoint being hit, > bpstat_stop_status() computes the stop_pc again, and corrects it. All > the info is printed correctly. I haven't looked at this in too much > detail though. I can add a FIXME to HIE to warn for the possibility of > problems down the road. I have no time now to try to fix this. > > > If you've tested the change on SPARC and i386, it's okay with me. > > I tested on sparc, I will test on linux. > > Elena > >From ezannoni@cygnus.com Tue May 02 13:20:00 2000 From: Elena Zannoni To: gdb-patches@sourceware.cygnus.com Subject: [PATCH] in_prologue() fix #2 Date: Tue, 02 May 2000 13:20:00 -0000 Message-id: <14607.14500.451080.510575@kwikemart.cygnus.com> X-SW-Source: 2000-05/msg00032.html Content-length: 4726 This patch supercedes the one in: http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00456.html This is a rewrite of in_prologue(). Jim is the real author of this patch, I have tested it on d10v (solves the original problem), solaris/sparc, linux/i386 w/ no regressions in the testsuite. I'll check this in tomorrow, if there are no objections. Elena Tue May 2 13:17:21 2000 Elena Zannoni (ezannoni@makita.cygnus.com) * symtab.c (in_prologue): From Jim Blandy. Rewrite, more intelligently, making sure we use the information from the symbol tables fully. Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.3 diff -u -p -r1.3 symtab.c --- symtab.c 2000/04/04 02:08:52 1.3 +++ symtab.c 2000/05/02 20:15:12 @@ -4402,43 +4402,64 @@ in_prologue (pc, func_start) struct symtab_and_line sal; CORE_ADDR func_addr, func_end; - if (!find_pc_partial_function (pc, NULL, &func_addr, &func_end)) - goto nosyms; /* Might be in prologue */ + /* We have several sources of information we can consult to figure + this out. + - Compilers usually emit line number info that marks the prologue + as its own "source line". So the ending address of that "line" + is the end of the prologue. If available, this is the most + reliable method. + - The minimal symbols and partial symbols, which can usually tell + us the starting and ending addresses of a function. + - If we know the function's start address, we can call the + architecture-defined SKIP_PROLOGUE function to analyze the + instruction stream and guess where the prologue ends. + - Our `func_start' argument; if non-zero, this is the caller's + best guess as to the function's entry point. At the time of + this writing, handle_inferior_event doesn't get this right, so + it should be our last resort. */ + + /* Consult the partial symbol table, to find which function + the PC is in. */ + if (! find_pc_partial_function (pc, NULL, &func_addr, &func_end)) + { + CORE_ADDR prologue_end; + + /* We don't even have minsym information, so fall back to using + func_start, if given. */ + if (! func_start) + return 1; /* We *might* be in a prologue. */ - sal = find_pc_line (func_addr, 0); - - if (sal.line == 0) - goto nosyms; - - /* sal.end is the address of the first instruction past sal.line. */ - if (sal.end > func_addr - && sal.end <= func_end) /* Is prologue in function? */ - return pc < sal.end; /* Yes, is pc in prologue? */ - - /* The line after the prologue seems to be outside the function. In this - case, tell the caller to find the prologue the hard way. */ + prologue_end = SKIP_PROLOGUE (func_start); - return 1; + return func_start <= pc && pc < prologue_end; + } -/* Come here when symtabs don't contain line # info. In this case, it is - likely that the user has stepped into a library function w/o symbols, or - is doing a stepi/nexti through code without symbols. */ - -nosyms: - -/* If func_start is zero (meaning unknown) then we don't know whether pc is - in the prologue or not. I.E. it might be. */ - - if (!func_start) - return 1; + /* If we have line number information for the function, that's + usually pretty reliable. */ + sal = find_pc_line (func_addr, 0); -/* We need to call the target-specific prologue skipping functions with the - function's start address because PC may be pointing at an instruction that - could be mistakenly considered part of the prologue. */ + /* Now sal describes the source line at the function's entry point, + which (by convention) is the prologue. The end of that "line", + sal.end, is the end of the prologue. + + Note that, for functions whose source code is all on a single + line, the line number information doesn't always end up this way. + So we must verify that our purported end-of-prologue address is + *within* the function, not at its start or end. */ + if (sal.line == 0 + || sal.end <= func_addr + || func_end <= sal.end) + { + /* We don't have any good line number info, so use the minsym + information, together with the architecture-specific prologue + scanning code. */ + CORE_ADDR prologue_end = SKIP_PROLOGUE (func_addr); - func_start = SKIP_PROLOGUE (func_start); + return func_addr <= pc && pc < prologue_end; + } - return pc < func_start; + /* We have line number info, and it looks good. */ + return func_addr <= pc && pc < sal.end; }