headers
Daniel Jacobowitz | 2 Jan 2008 04:17

Re: how to search for a global type?

On Sun, Dec 30, 2007 at 08:28:44PM -0800, Gary Funck wrote:
> static
> int
> lookup_type_by_name (const char *type_name)
> {
>   const struct symbol *sym;
>   const struct type *type;
>   int type_id;
>   sym = lookup_symbol_global (type_name, NULL, TYPES_DOMAIN, NULL);

Are types global, or do they usually end up in the file's static
block?  I'd guess the latter.  Check maint print symbols.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 4 comments |
headers
Gary Funck | 2 Jan 2008 06:16

Re: how to search for a global type?

On 01/01/08 22:17:50, Daniel Jacobowitz wrote:
> On Sun, Dec 30, 2007 at 08:28:44PM -0800, Gary Funck wrote:
> 
> Are types global, or do they usually end up in the file's static
> block?  I'd guess the latter.  Check maint print symbols.

Not sure (excerpt from maint print symbols follows).  The typedef
is defined in the runtime, not in the main source file.  Thus,
if I run up until "main" and try "maint print symbols", I don't
see the typedef at all.  If I position to one of the runtime
source files, then the typedef appears in the maint print
symbols output as below:

Symtab for file /upc/gcc-upc-4/src/libupc/smp/upc_access.c
Read from object file /upc/gdb-upc/wrk/a.out (0x954630)
Language: c++
[...]

block #000, object at 0xb40a30, 9 syms/buckets in 0x4015d8..0x4022bf, compiled with gcc2
 float __getsf2(upc_shared_ptr_t); block object 0xb363c0, 0x4017ff..0x401836
 void __putblk3(upc_shared_ptr_t, void *, size_t); block object 0xb3b0a0, 0x401b40..0x401b75
[...]
 int THREADS; unresolved
 long unsigned int __upc_page1_ref; unresolved
 void *__upc_page1_base; unresolved
  block #001, object at 0xb40990 under 0xb40a30, 6 syms/buckets in 0x4015d8..0x4022bf, compiled with gcc2
   typedef long unsigned int size_t;
   typedef signed char signed char;
   typedef long int long int;
[...]
(Continue reading)

Permalink | Reply | 3 comments |
headers
Daniel Jacobowitz | 2 Jan 2008 14:06

Re: how to search for a global type?

On Tue, Jan 01, 2008 at 09:16:26PM -0800, Gary Funck wrote:
> The typedef appears to be in inner block.  Does that make it static?

Block 0 is the global symbols; block 1 is the file static symbols.
Later blocks are the bodies of functions, et cetera.

It makes sense for types to be static if you think about it from the
right perspective, since types do not (generally) have linker
visibility; the linker can't patch up your code to reference a type
declared in another file.

In short, try just lookup_symbol?

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 2 comments |
headers
Gordon Prieur | 2 Jan 2008 18:22
Picon

Re: gdb cannot understand some type with STL


Eli Zaretskii wrote:
>> Date: Sat, 22 Dec 2007 12:35:07 -0500
>> From: Daniel Jacobowitz <drow <at> false.org>
>> Cc: gdb <at> sourceware.org
>>
>> It's going to be a std::list<int, std::allocator<int> > or something
>> like that.
>>     
>
> In which case "whatis 'std::list TAB" (note the single quote) should
> complete the correct text to type, right?
>   

Is this solution likely to work in mi mode? I've run into similar issues 
with gdb/mi
in the NetBeans gdb module.

Gordon
Permalink | Reply | 1 comment |
headers
Gary Funck | 2 Jan 2008 18:41

Re: how to search for a global type?

On 01/02/08 08:06:30, Daniel Jacobowitz wrote:
> On Tue, Jan 01, 2008 at 09:16:26PM -0800, Gary Funck wrote:
> > The typedef appears to be in inner block.  Does that make it static?
> 
> Block 0 is the global symbols; block 1 is the file static symbols.
> Later blocks are the bodies of functions, et cetera.
> 
> It makes sense for types to be static if you think about it from the
> right perspective, since types do not (generally) have linker
> visibility; the linker can't patch up your code to reference a type
> declared in another file.
> 
> In short, try just lookup_symbol?

I did try lookup_symbol() as well, no go.

I'm currently using this approach:

static
int
lookup_type_by_name (const char *type_name)
{
  const struct symbol *sym;
  const struct type *type;
  int type_id;
  struct symbol_search *matches;
  /* FIXME: add ^$ anchors to front/back of type_name, so
     that the regex matches only the desired type name.  */
  search_symbols ((char *)type_name, TYPES_DOMAIN,
                   0 /* nfiles */, NULL /* files */, &matches);
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 2 Jan 2008 18:56

Re: how to search for a global type?

On Wed, Jan 02, 2008 at 09:41:58AM -0800, Gary Funck wrote:
> I did try lookup_symbol() as well, no go.

You may need to trace how ptype finds it, then.  I would expect
lookup_symbol to work.  If there is no symbol in the global blocks, it
falls back to static blocks (not just the current file's).
search_symbols is going to be much less efficient.

> I think one difficulty is that the current file doesn't
> define the type.  It is defined in the runtime files.
> 
> I haven't tried following the logic, but could you briefly
> explain the raltionship between block vectors and symbol
> tables?

Each file has a blockvector.  Block 0 is its contribution to the
global symbol table.  Block 1 is its static symbol table, including
things like types.  Later blocks are children of one or the other,
representing functions (and further inner blocks of functions).

The symbol table is made up of the contents of those blocks, though
indexed differently (I think, I have not checked in a while).

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 2 Jan 2008 18:57

Re: gdb cannot understand some type with STL

On Wed, Jan 02, 2008 at 09:22:56AM -0800, Gordon Prieur wrote:
> Is this solution likely to work in mi mode? I've run into similar issues  
> with gdb/mi
> in the NetBeans gdb module.

No, I'm not sure how to handle this in MI.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 0 comments |
headers
Aleksandar Ristovski | 3 Jan 2008 16:20

gdb_realpath: dealing with ./ and ../

Hello,

First a question, to give an idea what I am talking about and then detailed
explanation.

Question: Should gdb_realpath deal with './' and '../' path elements and
compact them along with 'canonicalization' it already does?

Details:
Our binary was created from one compilation unit:
C:/foo/bar/main.cc
Our compilation directory is:
C:/foo/bar/Debug

When our cross-compiler generates binary, it stores relative path in
.debug_line section (relative to compilation dir), i.e. '..'.

readelf -wl output gives this:
...

  Opcode 6 has 0 args
  Opcode 7 has 0 args
  Opcode 8 has 0 args
  Opcode 9 has 1 args

 The Directory Table:
  ..

 The File Name Table:
  Entry	Dir	Time	Size	Name
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 3 Jan 2008 16:55

Re: gdb_realpath: dealing with ./ and ../

On Thu, Jan 03, 2008 at 10:20:19AM -0500, Aleksandar Ristovski wrote:
> Hello,
> 
> First a question, to give an idea what I am talking about and then detailed
> explanation.
> 
> Question: Should gdb_realpath deal with './' and '../' path elements and
> compact them along with 'canonicalization' it already does?

The problem with this idea is that removing ../ is not reliably
correct.  On Unix, symlinks allow foo/../bar and bar to be different
directories.  We should only canonicalize paths to local files, not to
files mentioned in debug information.

gdb_realpath shouldn't need any changes to handle ..; it works from
the local filesystem and constructs a real canonical path.  I see that
you're on Windows.  gdb_realpath may not handle Windows correctly;
libiberty's lrealpath does and I don't know why we still have both.

> When our cross-compiler generates binary, it stores relative path in
> .debug_line section (relative to compilation dir), i.e. '..'.

What's in .debug_info?  Also, what version of GDB?

> It loads line table, finds '..', constructs absolute path using compilation
> directory and creates "C:/foo/bar/Debug/../main.cc" and then compares this
> (using FILENAME_CMP macro) to existing subfile-s and fails to find it (file
> buildsym.c, function start_subfile).

I have:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aleksandar Ristovski | 3 Jan 2008 17:33

RE: gdb_realpath: dealing with ./ and ../


> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow <at> false.org]
> Sent: January 3, 2008 10:56 AM
> To: Aleksandar Ristovski
> Cc: gdb <at> sourceware.org; Ryan Mansfield
> Subject: Re: gdb_realpath: dealing with ./ and ../
> 
> On Thu, Jan 03, 2008 at 10:20:19AM -0500, Aleksandar Ristovski wrote:
> > Hello,
> >
> > First a question, to give an idea what I am talking about and then
> detailed
> > explanation.
> >
> > Question: Should gdb_realpath deal with './' and '../' path elements and
> > compact them along with 'canonicalization' it already does?
> 
> The problem with this idea is that removing ../ is not reliably
> correct.  On Unix, symlinks allow foo/../bar and bar to be different

On linux, when realpath works all is fine and it will take care of the
symbolic links. However, the problem starts when paths do not really exist
and realpath fails. A simple example is my cross-compiled binary built on
windows, being debugged on linux. In this case, when realpath fails, I would
like to 'compact' or 'normalize' the path by resolving relative path
elements (and current path elements) thus forming canonical path, whithout
resolving symlinks (which can not be resolved since they do not exist).

Additional problem is on windows, where realpath doesn't work and
(Continue reading)

Permalink | Reply | 1 comment |

Gmane