This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PING: [RFA] Runtime Dwarf2 CFI engine cleanup


On Wed, Feb 26, 2003 at 04:35:20PM +0100, Michal Ludvig wrote:
> Michal Ludvig wrote:
> >Elena Zannoni wrote:
> >
> >>Michal Ludvig writes:
> >> > Hi all,
> >> > the attached is a fix for the problem described here:
> >> > http://sources.redhat.com/ml/gdb/2002-12/msg00246.html
> >> >  > I've created a new function cleanup_cfi() in dwarf2cfi.c that 
> >>deletes  > all CIEs and FDEs of objfiles removed later by 
> >>objfile_purge_solibs().
> >> > So far it works fine but I don't know how should I correctly call it.
> >>
> >>I have tried your function, and it does fixes some weird errors which 
> >>occur
> >>on rerun.
> >>I just tried by using the hack of defining GDB_TARGET_IS_X86_64, which
> >>is definitely a bad thing.
> >>
> >>I think that the best way is to define a gdbarch method, just like it
> >>was done for gdbarch_dwarf2_build_frame_info.
> >
> >
> >How about adding dwarf2cfi.o to all targets? When there is for example 
> >mipsread.o compiled into gdb on x86-64 (why? because there is no option 
> >to say what features a given target needs.) than dwarf2cfi.o could go 
> >there as well...
> >I hope more and more targets will use it in the near future.
> >
> >The attached is a version that adds dwarf2cfi.o for all targets. If it's 
> >unacceptable this way I'll provide gdbarch-ed version instead. But I 
> >think that gdbarch_*() functions are good for the case when on different 
> >targets a different functions are called to do a given task (eg. read 
> >register). But in this case you must call cleanup_cfi() in all targets 
> >that use CFI. No option. Calling it shouldn't depend on setting gdbarch 
> >value. Instead it should depend on linking dwarf2cfi.o into the gdb.
> >
> >>In the patch below, you cannot use printf's. Use printf_filtered. But
> >>maybe, better yet, using a warning here would be more appropriate.
> >
> >
> >It isn't a warning, just an informational message. Now it's printed only 
> >when info_verbose is set.
> >
> >>Watch out for the non-GNU indentation and spacing.
> >
> >
> >Reindented.
> >
> >OK to commit?
> >
> >Michal Ludvig
> 
> Could someone *please* comment on this two months old patch?
> Can I at least commit the dwarf2cfi.c part (proven to be stable since 
> it's in use in our GDB package), so that it could eventually be 
> triggered by adding one single line to infcmd.c?
> Without this patch the CFI engine is very unstable. Is there a reason 
> why not to commit it?
> 
> Ad triggering cleanup_cfi() - there are several possibilities:
> 1) Add dwarf2cfi.o to all targets in Makefile.in and call cleanup_cfi() 
> from run_command() w/o obstructions.
> 2) To all targets that use CFI add macro USE_DWARF2CFI to their 
> config/what/ever.h and wrap call to cleanup_cfi() by appropriate ifdefs.
> 3) Create gdbarch_whatever(_p) to call it. I don't think it's a good 
> idea - there is no point in setting this macro to something else or 
> unsetting it.
> [in order of preference]
> 
> I would really like to get rid of this pending patch from my todo list.
> 
> Thanks in advance


I don't think that the way you're selecting objfiles to unload is ideal
- you're duplicating logic from objfile_purge_solibs.  We need a more
general hook to free objfile-specific information.  However, I believe
that can be addressed separately, and this will definitely fix some
crashes as-is and not introduce any new ones.

I don't have any problem with linking dwarf2cfi.o in for all targets. 
Let's sit on this for another day and see if anyone else objects, and
then you can commit it.

You made a line in Makefile.in too wide; please fix that before you
check it in.

[List: my assumption in approving this is that the dwarf2cfi support is
not part of the dwarf2 reader, so I'm not stepping on anyone's toes. 
If you disagree, please tell me so.]

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]